What are the security/performance implications of such a solution?
You have two layers of encryption (SSH and OpenVPN), which might reduce performance – higher CPU usage and lower throughput, especially if one of your three involved devices doesn't have hardware crypto acceleration. (Even then, the SSH software rarely provides top performance.)
You also have three layers of nested TCP flow control (your regular traffic, inside the OpenVPN layer, inside the SSH layer). This might not work well.
Finally, throughput will be reduced by the tunnel overhead alone (SSH and OpenVPN packet headers eating into the available baseline 1500-byte MTU). Of course, one layer is unavoidable for a VPN, but doubling it might be noticeable.
direct: IPv4 <20> | | TCP <20> | application
vpn: IPv4 <20> | UDP <8> | OpenVPN <41> | IPv4 <20> | TCP <20> | application
yours: IPv4 <20> | TCP <20> | SSH <~20–40> | OpenVPN <41> | IPv4 <20> | TCP <20> | application
Is there a better way to do this?
As you already have a VPS, put the OpenVPN server there – and have your home system connect "out" to the VPS instead of the reverse. (Yes, the OpenVPN server will forward data between your 'home' and 'roaming' clients with no problems.)
This way you'll even be able to use UDP without any NAT-related problems, as long as you enable periodic ping in the client or otherwise maintain frequent traffic over the tunnel.
If you're using tun-mode VPN, the server just needs a kernel route for your LAN subnet through
tun0, and then an OpenVPN iroute for the same subnet through the home VPN client's address. (With tap-mode VPN it's just a single kernel route combining both.)