So to me this is one of those things that seems unnecessary when an app is small and/or new but eventually you code yourself into a corner and realize where the idea of separation of concerns came from.
The best example in recent history is wanting to change your front end framework. If you have good decoupling you likely can leave your models in tact and migrate in a new framework in pieces. These days it seems like react is going to take us to the end of the earth but I remember quite painfully buying into a highly coupled angular 1 app, then buying into another highly coupled ember system only for them to die and having to so revolutionary migrations.
It’s also easier for later maintainers who anticipate models and views living differently as they handle different things. Moving these two together on a larger codebase can leave one feeling like they are looking for the glasses in someone else’s kitchen. Some of these conventions help us reason about things and find our way around an unfamiliar code base.
Good decoupling really does pay dividends over time in my opinion. At the outset it seems like a burden but there usually comes a day where you wish you had effectively decoupled different concerns in your code.
Thanks, Mike, for your detailed comment.
Everything you said is valid, but from my experience building a lot of small to medium single-page applications, the "model" in the frontend doesn't contain much business logic.
Since the backend is the source of truth, it has to implement all the business logic, and if there is some logic running in the frontend, it is probably backend logic that we duplicate to make our apps feel more reactive (i.e., optimistic updates).
So, in the end, my frontend models are mostly composed of views.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.