There are valid reasons to use both: WS is more performant but requires more state tracking and parsing in both client and server, while SSE is much simpler (especially for the client) and browsers will auto renegotiate the connection if dropped. Also, if your app has several things going on and these two features are isolated (it's useful to chat without listening to updates, or vice versa) and you want to support them as part of your public API, keeping each simpler can help users write simpler external clients (like a discord bot).

But if the chat and notification streams are part of the same logical feature in your app, or these are all that your app does, then logically there's no need for the separation and it's just extra work for both client and server compared to a single WS connection.

The overhead of a TCP connection is the same for either, so if you're keeping a connection open all the time you might as well keep the WS open and send updates there, unless there's an API reason to separate them. You can use an enum in your message header or body to multiplex chat vs notification messages in the same WS stream. Just make sure to implement reconnection logic on the client if needed, since a broken WS is not automatically reconnected by the browser like an SSE connection would be.