Thanks for your response. You are correct, and I believe due to it's massive bandwidth requirements (100MB+) is why it's used in closed environments. You can see a recent real world example of Riot Games running LCS here: https://www.sportsvideo.org/2020/03/27/riot-games-keeps-league-of-legends-esports-rolling-with-fully-cloud-based-virtualized-production-workflow/
They have a nice diagram showing their infrastructure running in AWS. Using best-in-class software will make the production crew most efficient and use things like VMix for what it's good at (replays) and OBS for what it's good at (encoding in the is case, but it is also better at transcoding than VMix from a lot of testing. VMix does not expose custom ffmpeg options as an example).
Imagine using a cloud service for your full production environment. 4 production machines and a nimble streamer instance. One of those machines can be used for web cameras for a team, another can be used for web cameras for another team (and in this case VMix calls are just "easy", so vmix would be best in class here). You load up VMix, you start adding scenes, you start mixing, and you start producing. You're getting observer feeds (the people who are sending SRT of the game feeds to your nimble instance and then over to VMix or OBS, somehow). One angle here is to possibly run the game in the cloud and have an observer use something in close proximity and send the feed over NDI to VMIX directly instead of hitting VMix. You get to the point where you now need to encode the final product and transcode it for Twitch or another streaming service. Well, unfortunately VMix transcoding seems not up for the job. A lot of folks use it for things like replays and like I mentioned earlier, during physical events we don't see a lot of network protocols being used.
Cloud production is going towards becoming a commodity. We are not using NDI over the internet. We are using Nimble to be our interface between internal ("LAN in the cloud") and external (from the Internet, SRT example). We would like to deliver the internal streams via NDI. It's because NDI is easy on system resources at the expense of bandwidth which is ample and cost-free if you're not leaving a provider.