I will confess you that I didn't read a lot about Hubitat's websocket and how it works.
I've chosen webhook only because it was officially supported, nothing more.
The following answers are only my opinion/preference
The main advantage of websocket is that servers don't need to be reachable by both sides. If Node-RED is behind a NAT, then is simplifying the configuration. But I don't think that facilitating complex architecture is the priority of Hubitat (which is fine).
For this plugin, it will remove the awkward webhookd configuration section that nobody understand (without reading doc) 
A disadvantage of the websocket is to maintain the connection and handle reconnection. For all other performance issues, we can often improve the code and the desired performances depend on the use cases
I don't like this kind of architecture. I prefer separate events (weboscket) from commands (API).
True. Does the websocket is authenticated? Even if the websocket is already used internally, it's maybe not ready for being used by other external components
Do you talk about the initialization process of requesting all devices data? If yes and someday, it cause issues on this plugin, then there are probably some improvement that can be done on the plugin side (ex: requesting only one device for all the same device node).
True, but without any metrics I will not be too worried about this. 
I saw argument about that using a lot of webhooks can decrease the hub performance. Then I would say that if you want to have more than 10 (which is an arbitrary number) webhooks configured, just proxy it in another tool and use your own broker.
Anyways if one day, websocket become official, it should be authenticated (if not already) and maybe add the ability to filter events by event types. Meanwhile, we can also make a websocket node to receive all events (those we cannot have with webhook) and use both (websocket/webhook)
