Is there any reason why one couldn't run FIX message traffic *over* websockets?

Disregarding the session layer for a second, a low-fidelity application of FIX over websockets could simply use the typical HTTP upgrade websockets handshake, then simply exchange message traffic formatting with FIX traditional tags and values for a particular data dictionary version.

Bringing the session tier back into the picture, it shouldn't be too difficult to devise a handshake that maintains the spirit of FIX session initiation yet simply uses websockets over tcp+ssl to communicate.

I suspect many trading venues in the crypto asset class originally launched with both REST and WebSockets support, with FIX support subsequently added as an enhancement.  One drawback is that this imposes upon the venue a need to maintain multiple, distinct versions of application semantics, the building blocks of which FIX does an excellent job of defining at very granular levels.  FIX can be intimidating to those new to it, and likely doesn't make sense to implement in 1.0 for a crypto-native market center.

As bigger players with an established legacy infrastructure onboard crypto asset classes, the demand for FIX connectivity to integrate should increase.  I think that discovering the ideal mechanism to run FIX session using websockets as the wire is beneficial, since it would save the exchange development personnel the effort of manufacturing API semantics independent of any larger recognized standard.