As a separation pattern MVVM aims to provide 3 specific benefits:
#1 Collaborative workingBy separating the visual part of the app (the user interface, or UI) from the related code it becomes possible to have specialists in each area work on related items at the same time. The theory is designers can work on the UI at the same time as developers are working on the code without needing to have them both work on the same files at the same time.
Unfortunately, very few people see this benefit as they don't work in teams or on projects where the are enough people with specific skills on the design and development sides that they can work on both simultaneously.
#2 Code reuseDoing the same thing multiple times gets boring quickly.
Having the same code in more than one place creates a duplication of effort when the code if first created and adds extra effort to maintain the different copies of the same (or very similar) code.
As a separation pattern, one of the intentions is that it allows the different layers to be reused. The model layer is the most obvious candidate for use in multiple apps or versions of an app (i.e. for different platforms) but ViewModel should be able to be reused as well. If you're only building a single app for one platform you have an excuse for ignoring this but if your ViewModels could be being used on multiple platforms then they should be. The biggest barrier to being able to do this is having ViewModels that reference or are strongly tied to something in the View layer or the UI of a particular platform. The associated downside to this is that it also makes testing hard.
#3 Ease of testingOne of the long-time criticism of apps with graphical UIs is that they are hard to test. A separation pattern, like MVVM, should break the coupling between the application logic and the UI and so make testing more accessible. It shouldn't be necessary to do all testing via the UI and so tests become quicker and easier to set up and run. Sadly, many developers using the MVVM pattern still aren't getting the benefits that come from automated testing. Or, they're still creating links between the layers of the app that make automated testing much harder than it need be.
It is disappointingly common that I see apps and developers who are not getting any of the benefits mentioned above. Such developers are still enthusiastic about the pattern and encourage others to use it because of secret bonus reasons numbers four and five.
bonus #4 Bindings make UI updates easier to handle
Bindings simplify many of the challenges of manipulating data, capturing entered data, and monitoring changes. While definitely useful, this shouldn't be the only benefit you get from the MVVM pattern.
bonus #5 Ease of maintainabilityBy having a separation between the different parts of an app's code it brings a level of structure and uniformity to the code. It's easy to see where things should go or where they're likely to be. It also encourages the use of other patterns (dependency inversion, services, messaging, etc.) and so brings the benefits of good development practices. These aren't unique to the MVVM pattern. The benefits come with almost any architectural pattern that is followed and applied to a codebase.
Just because your code has some classes with the suffix ViewModel that you bind to your views doesn't mean that you are getting the full benefit the MVVM pattern could be providing.
This may or may not be an issue but I can almost guarantee that your codebase would be better served by having more tests. ;)
Do you use the MVVM pattern? What benefits do you get from it?