I think you are looking at this in completely the wrong way. A GUI app and a web page are worlds apart so the exact same definition of MVC will never work for both. MVC is more about the ideal: separating certain parts of the app like display and logic.
In PHP (or the web in general), a View is the web page itself: the HTML output. It's not "live" as per your definition, but you simply click links to go back to the controller (i.e. another page request).
The Controller and Model is where things do differ, like you explained. In PHP the model tends to be the data layer, interacting with the database and so on. But it is still modelling the situation, and the controller still controls the application flow, if only once per page load.
So the name "Model-View-Controller" is perfectly logical, albeit a different implementation in GUI apps vs web apps.
Learning OOP is definitely worth it. Passionate hireable developers are always willing to learn to expand their knowledge, specially when you can save time in the long run. I would agree more with the second group of people:
Others say it's incredibly stupid, you're not scaleable, you're never
get serious funding, you're the only one who ever be able to work on
the project, you should stop and start learning it now, etc.
That's a bit harsh, but the reality is, the more you know, the more you scale. Serious funding is often surrounded by hype, and procedural code is unfortunately not cool enough. OOP and frameworks are.
Am I doomed? I feel lost. My personal opinion on this is, that even
though it is a huge system already, it is still a MVP and I guess at
some point in the future we would rewrite the code anyways [...]
Large procedural code bases are not uncommon, see WordPress. OOP really helps to abstract and organize your code without relying on procedural conventions (although MVC frameworks have a whole different set of conventions). WordPress started a migration process, that's still going on today. With such large projects all you can do is upgrade your system, step by step, testing that nothing breaks, and keep re-factoring, forever, as you'd introduce new features that will need refactoring later on.
But no, you're not doomed, just a little bit late to the whole process. Learn what you can when you can; less is better than nothing. The learning curve when learning new programming paradigms, or languages, is often steep at first, but after that first hiccup it'll be smooth sailing, and you'll start to really appreciate the difference it can make on your code, and the difference it will make when others read your code.
Edit: Just to clarify, I'm not suggesting the current system needs to be OOP, or that it needs to be built from scratch. Any system is going to be re-factored, at some point, and you may need to break compatibility with previous system, and that's fine if the project requires it; you can have a deprecation cycle as well. What I'm suggesting is to slowly introduce OOP as you refactor your current code, namespaces, etc.
Best Answer
In a complex routing system, generally a controller should be looked up by a name that is based on what its job is or what route it handles. When your app "boots up" you register controllers under those names so that the class name isn't hard coded everywhere, allowing you to swap out controllers easily. This is what the
Appfacade in Laravel does.There is nothing wrong with using static classes (abstracts with final private constructors) in place of singletons (I personally think they are preferable to singletons), and if you know your core won't grow too much then this is fine. The drawback is if you ever want to switch to the more dynamic way of doing it you're going to have to refactor.
An ideal MVC is thin. As Laravel's creator Taylor Otwell put it, be careful not to box yourself in to a "pure MVC" paradigm. A web service consists of more than MVC; MVC is just a pattern, not an architecture.