Very much different. He explains it in the article quite clearly. No need to manually configure clients to use the proxy, as it uses the client's firewall to forward connections.
"sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It's just data-over-TCP, which is safe."
I haven't bothered to look at how this is actually implemented, so I can't comment on how it actually works.
As far as I know it sets up firewall rules (ipfw/iptables) to redirect certain outgoing TCP connections to a local socket, where they are picked up by the sshuttle service and multiplexed over the ssh connection. at the other end, the stream is demultiplexed into connections again. Definitely no individual packets.
I've heared the claim that TCP over TCP doesn't work well countless times. I've been using OpenVPN in tcp mode for at least 5 years on a daily basis and never noticed a problem. I've even done SIP over a TCP OpenVPN configuration without a noticeable problem.
It makes sense to me that it should perform badly, and it probably does for uses cases with a lot of traffic, but for an average user on a laptop, a TCP based VPN is fine.
In my experience it depends heavily on what you are doing. When I'm just sending files from one place to another through my SSH VPN, it performs reasonably well. When you actually try to do something interactive, as in, interactive over the network, like a VNC or X connection or even just get intensive enough with a remote vi session, performance can and does randomly tank. sshuttle works far better for that use case. (I stopped using it because it didn't do DNS and I didn't have the time to add that but the commit log implies that has been fixed.)
What happens is you essentially get "infinite bufferbloat." When there's no packet loss, you end up absolutely filling the transmit buffers at the entry points to the tunnels. The result, as other people have mentioned, is extremely poor interactive performance when you're simultaneously transferring large files.
TCP-over-TCP not "broken" in the sense that the sessions will randomly drop or your kernel will crash or anything. It's just that doing it correctly is much better.
Mind you, given the prevalence of bufferbloat (mostly caused by misdesigned routers/DSL/cablemodems) nowadays, interactive performance already largely sucks when you're transferring large files. So you might not even notice a difference.
