Mediasoup has a bit more modern codebase and offers a rather low-level framework to build your own SFU. Whereas Jitsi videobridge is more of a ready-to-go SFU, but less flexible.
Mediasoup has very good node bindings, which may or may not be an advantage to you.
They offer similar (good) performance, although Mediasoup has a slight edge here. They're both very actively being kept up to date with the latest standards (in contrast with Kurento which is now as good as dead after Twilio bought the team). This is very important since both the spec and browser implementations are a fast moving target.
Disadvantage of mediasoup is that it is mainly maintained by just 1 or 2 persons and not yet used as much as Jitsi, so it's a bit of a gamble to start building your product on top of that.
mediasouop is not an application but a set of server and client low level libraries to build whichever kind of audio/video applications (not just meetings). You don't "install mediasoup and configure it". You create your Node app and integrate mediasoup as you do with any other NPM dependency. Same in client side. More here:
https://mediasoup.org/documentation/overview/
Of course, this means that you must build your application, including UI, client-server signaling, etc etc.
Is live streaming a use-case that's under scope? If so, can the client P2P or requires a relay server for all traffic?
webRTC is peer 2 peer, but that doesn't work if you have a lot of peers. That is where an SFU like mediasoup comes into the picture. That's a kind of relay server so you can send to many peers still over webRTC (thus with ultra low latency). Also, if the peers are behind firewalls, peer 2 peer also doesn't work and you need a TURN server to relay the video.