Again? Okay, so if you really want to choose, choose MVVM. Usually forget data-binding, unless you are working on a really small thing where the performance does not matter. Otherwise don't shy away break any rules you need to deliver the thing you want and on a preformant manner on your choice of target device. And I'm serious. And if you want to read long and probably boring debate about these things, just search the forums, we talked about this multiple times. Don't forget, games aren't business applications, you need to make them differently.
We clearly haven't had enough people trying to approach this game engine in ways that it wasn't intended to be used.
I'm not even sure how this would work. A MonoBehavior script can be a model, sure, but what's the view and controller? A scene being a view and the SceneManager being the controller are the closest things I can think of, but they don't even have any correlation to the model in this context.
You have a full .NET environment at your disposal. If you consider the Unity scene and/or GameObjects to be your "View" then your model and your controllers can be whatever you want to code up. I've seen this approach used to quite some success in the past. It certainly doesn't have to be the performance nightmare that people may easily imagine.
Use MVVM for the UIs if you have a game with complex UI. Thats about it., Also if you use the menus in game (Overlay over the main game) make sure the MVVM framework do not allocate etc as it can ruin performance for rest of game.
Checkout StrangeIOC, it has a nice MVCS system. I have integrated it into my project and like it so far. https://strangeioc.github.io/strangeioc/