The way plugins/backends work in this is fundamentally different. Video.js at it's core does very little and doesn't provide a very strict API. The result tends to be that every ad provider you add on does things slightly differently. If you want to build advanced metrics on top of a video.js instance that can use two different ad providers, it's likely you'll have to manually fix up the ad events to make them track correctly. This project includes base API definitions for all important ad events that other extensions can hook into with set guarantees on how they'll behave.

Another thing is how extensions are dealt with here. In video.js, if you need DASH support, you'll add videojs-contrib-dash and dash.js. Together that's at least 500kB of JS extra. Even in Safari where you won't need any of those, you'll have to do some hacking to avoid loading that JS for no reason. In Indigo here, dynamic bundle loading is core to the extension setup. When reading a config there's a lightweight check to determine what library to use for playback (if one is needed at all), and it'll only be loaded when it's necessary. In Safari, where you generally don't need any libraries, nothing will be loaded. In Chrome, you'll load Shaka when you want to play DASH, and hls.js when you want to player HLS. Indigo makes that very easy (and a default), video.js makes it hard.

These are advanced problems though. You're not likely to hit these issues with video.js if all you do is play a simple stream without DRM and with one single ad provider. But the solutions to those issues that are a core part of this project actually provide benefits in all situations and make development easier, so it's a net win for everyone in the end.