I think the trick to bypass this kind of nonsense is to use port 443/1194/53 so QoS + firewall rules will still allow the VPN to pass through.
Haven't tested it yet, but in my experience non-default ports only make the problem worse. Most filtering/QoS services are pretty dumb and will just match source and destination ports; most firewalls will just plain ignore everything targeted at port 443 because the moment you start messing with HTTPS, you're in for a world of pain. Because WireGuard uses UDP, it's possible to listen on port 443 even if you're already hosting an HTTPS website. Sadly, you won't be able to use QUIC or HTTP3 if you do, but I don't think that's much of an issue these days.
Should still be possible. Xs4all had port 80 set up so that if you'd SSH to it, you'd get connected to their shell while with a browser (the normal modus operandi) you'd end up on their website. It worked very well in some of the more oppressive regimes where traffic to port 22 was blocked.
I also don't serve HTTP(S) content on my home connection. I only host WireGuard, that's part of the point.
I haven't contacted EE about it or tested other VPNs yet. I want to run WireGuard for various reasons so switching to OpenVPN might confirm they issue but not solve my problems (I don't run the VPN for the reasons in the OP)
That being said, have you attempted to discuss the issue with them? Have you considered a non-default UDP port? Also, did you compare the usage with OpenVPN? I ran OpenVPN before, the roaming, network speed, and latency is quite terrible.