If you already have an authenticated session via http in Express, then a socket.io connection is really JUST another http connection (it actually starts with an http connection and is then converted to the webSocket protocol (with a socket.io layer on top). So, if you're willing to trust the session for the next http request from that client, then it is no different to trust the session for an incoming socket.io connection from that same client. They are the same thing.
Where it might be useful to auth a socket.io connection from scratch would be when you don't already have an authenticated http page that the socket.io connection comes from, either because the socket.io connection is its own API and own service, perhaps even on a separate host so there is no "other" auth to rely on.
Is there a need to use both approaches for authentication if you are already sharing sessions with express.
No. You can just use the express session you already have in order to now that the socket.io connection comes from the same client.
Does it add any security advantage?
Only if there's some reason you want to require auth on every new request and not rely on a session cookie at all, even for http requests. Or, if there is no session cookie because the socket.io connection goes to a different host.