I'm not sure how complicated (or how stupid) this question is, but what's the difference in security between using this versus an SSH tunnel as a proxy?
* The underlying SSH protocol dates back into the 1990s, is cryptographically inferior to WireGuard, and does not have an especially strong track record (it's record is similar to that of TLS).
* SSH is opt-in secure for a selection of ports; WireGuard (really, any real VPN) is default secure for all traffic, which is why you use it.
Mostly, though, the reason you'd use a VPN instead of SSH is that VPNs are easier to use. The reason people use SSH instead of VPNs is that most VPNs are hard to set up. That's a big part of what WireGuard fixes.
SSH tunnels are not VPN tunnels. SSH will act as the endpoint for your TCP application and only tunnel the application payload over SSH (TCP). On the other side a new TCP session will be opened over which that payload is sent. So you never do TCP over TCP.
It's more so a proxy than a tunnel and that avoids the real issue, which is nested congestion control. In addition SSH should also be able to do so with less overhead (in bytes) than a VPN (which need to forward the IP and TCP header intact), but I don't know how well SSH takes advantage of that.
SSH tunneling can outperform OpenVPN running in TCP or UDP mode.
Would you say this is true even if you configured openssh to only use the more modern options?
In recent years they've added a chacha20+poly1305 option as well as Curve25519 for key exchange and ed25519 for host and user authentication.
This would seem to bring it up to about an equivalent level cryptogtaphically speaking, in terms of application security, it's definitely more complicated, but it's also one of the most proven pieces of software around and much of that complexity is post-auth. The wireguard site itself pretty clearly states that it hasn't seen much in the way of field testing, though it does look extremely promising. I'll definitely be keeping on eye on it once it's available on more platforms.