There really is no generic answer to this question. There are only answers in the context of your specific application, its features, its design goals, the specific consequences (both positive and negative) for allowing multiple connections, its scale goals (is clustering involved), what UI complications there are by allowing or disallowing multiple connections, what server-side complications there are by allowing or disallowing multiple connections, etc...
There is no generic answer here.
Enforcing a Single Web Socket Connection per User
First off, this article describes a specific application (a game) that has a specific design goal to prevent a user from accessing the server through more than one page at a time because the player could perhaps create an unfair advantage in doing so. That's a valid reason for enforcing a single webSocket connection per user. Nowhere in that article is it indicated that this is done for any other reason than that.
Is there any disadvantage in enforcing a Single Web Socket Connection per User?
It really depends upon your application, your server implementation and your design goals. Limiting a user to one functioning webSocket means that they can only have one active tab, window or device open at a time. For a few applications, this is a desired thing. For others, it just over constrains the user with no benefit to the app or user.
When you implement this limitation, you have to figure out what you're going to do for a whole bunch of circumstances and how you make sure the user still has an appropriate (and good) user experience. For example, supposed I have a browser window open in my desktop and (without closing it), I walk out the front door and want to open the same site on my phone. If the phone's web browser is denied access to the site or denied proper functionality because there's already a webSocket open for that user on a different computer, then that leads to a frustrated user who suddenly can't use the app. There are numerous other edge cases like this that all have to be carefully thought out and designed appropriately.
So, I'd argue that in most cases, it creates far less user-experience edge cases if you just let each window the user opens have it's own webSocket. You can have the app time things out after inactivity in order to eventually clean up sockets that are inactive and make sure that has a clear user interface in the inactive page if a user returns to that page in the future.
So, a clear disadvantage of enforcing a single webSocket connection per user is that you have lots of use cases to think through how exactly it works for the user and is the user always clear what's happening and can they always do what they intend, particularly when changing devices or accidentally opening a second window for the app.
it makes the server side logic less complex among others
Well, this really depends upon the app design. If a webSocket is just interacting with its own web page, then allowing each web page to have its own webSocket is no extra complication at all. If, on the other hand, the purpose of the webSocket is to keep all open screens for that user up-to-date with the same information, then your server needs to not just send info destined for one particular user to only one webSocket, but to each webSocket for that user. Since, most apps already have some sort of mechanism for finding a webSocket that belongs to a given user, this just means that instead of only sending a message to one webSocket, it sends to all the webSockets that belong to that user. This logic can usually just be hidden behind a function that everyone can call. In socket.io (a layer on top of webSockets), one can use the rooms concept to keep track of all the sockets that belong to a given user.
Is it a common/good practice to do so when creating real-time applications using websockets?
That's not been my experience in using applications that have some server-push aspect to them (like stackoverflow, for example), though it isn't always obvious whether an app is using a webSocket or some other mechanism for getting updates to the UI. How often do you get some type or error or message if you try to open a second window on a server? That rarely happens to me.
Is there any need/advantage of Enforcing a Single Web Socket Connection per User if socket.io and express are sharing sessions?
No, there is no need to enforce it. With any sort of user login, you can easily share user sessions among all connections belonging to that user if that's your design goal. Keep in mind that it's application specific whether you always want the same session for all connections by the same user. It really depends upon the needs of the application and what you are doing with the session.
Or is it fine to allow a user to have multiple socket connections as long as they are all linked to their user._id or something that identifies them?
Again, this is application-specific. In most cases, I know of it's fine and limiting the user to only a single tab/window will just be seen as an unnecessary design limitation by many users.
