If you are using secure web sockets (wss), this shouldn't be an issue as the traffic goes over port 443 and the proxy won't be able to tell if it's HTTP or another type of traffic.
I can't speak to that vulnerability, but from what I have read websockets are more likely to not break on firewalls because they are using a well known port (either 80 or 443). Websockets also start out looking like a standard HTTP request. Compared to say MQTT or another protocol which uses its own port, websockets don't require any special setup. However, that really only applies to encrypted websockets; unencrypted has been known to cause issues with older proxies.
Furthermore websockets mask the payload so that naive proxies that do deep packet inspection to find HTTP requests don't fall to the poisoned cache trap.
Websockets don't use standard HTTP requests other than using standard ports. The header lines not mentioned in RFC 2616 get removed by a lot of corporate firewalls (that includes filtering proxies etc.).
I've never seen that. Also, this would break many websites that are part of the HPKP preload list I would think (need to double check), which include most popular websites.
However, I've often seen port 443 being blocked :|.
It's quite common in corporate networks. Locally installed CA certificates (i.e. anything that's not in the original root CA list) are exempt from HPKP rules for this particular reason.
I'm aware of corporate MitM proxies, but it's less common to run into these kinds of issues if you simply use wss://, because a) they're not quite as common as your typical ancient HTTP caching proxy and b) there's a better chance they either support new protocols natively or at least support HTTP CONNECT (like squid).
