Because websockets can traverse almost any network conditions. (This isn't a full TCP layer running over TCP), if that's what you're worried about. Feel free to kick the tires, or watch a video. The performance is equivalent or faster than a SaaS tunnel, but you can run an exit-server wherever you like, to lower the latency.
So if I understand correctly you're not running TCP inside the websockets, right? but if I'm e.g. using SSH the layers will be TCP-SSL-HTTP-WebSockets-SSH payload am I right? That sounds definitely better than TCP in TCP indeed.
And why do you say "websockets can traverse almost any network condition"? I mean I get that all my remote devices will keep a websockets connection to my "central" server, which is the one that should be reachable, and I can run whatever I want inside those websockets tunnels - is that what you mean? That we rely on outbound traffic to e.g. 443/TCP being allowed?
Also WireGuard is not a SaaS product, it's a technology. You can run IP and TCP inside a WireGuard tunnel, so not sure which approach would show better performance. Have you ran any tests?
Some other SaaS have built products that use WireGuard as core technology and allow clients to (try to) connect directly, thus lowering latency compared to any option with a jump server in between. The thing is you can't do that with TCP. Would you consider supporting UDP in the future to add direct connections (accomplished by e.g. UDP hole punching)?