There are no clear standards on how to structure the "M" layer of an MVC application. That being said, I have consistently come across problems with using business classes (or domain models, or ORM models) in the view layer of an application.
- Display logic sneaks into business classes
- Display logic gets peppered all over view templates
- No clear indication to the programmer of what is absolutely necessary to generate a view
- Presentation specific validations end up polluting classes that are not meant to be about the presentation
Business classes get modified to allow invalid data according to business rules, because the class is used to render a form (and therefore must allow invalid data to be entered)
This is the big reason to separate view models from business classes!
For this reason I almost always create view models for my views -- about 99% of the time. There isn't much extra effort to create a view model, and it gives you a place to put presentation specific logic. Having that separation in place from day 1 prevents an imminent refactoring later when the needs of the user interface expand.
This refactoring happens. Every. Single. Time.
Even if your business classes and view models have exactly the same properties, it's OK to copy data. It's not OK to copy logic. And it's not OK to mix presentation logic with business logic (or data storage logic).
Separating view models and business classes boils down to Separation of Concerns and is just plain good object oriented design.
In frameworks like ASP.NET MVC using Razor templates, you don't get compiler errors in your views when you rename a property or class name, which complicates refactoring. If you have a view model, your business classes can be refactored as you see fit, and you'll get compiler errors in your view models for incompatible changes.
If you used your business classes directly in your views, then you get a run time failure, which is harder to debug and takes longer to unravel.
Concerning YAGNI (You Aren't Gonna Need It)
The YAGNI principle tells us not to build things that are unnecessary. The problem is, user interfaces and business rules undergo a lot of change over the life of an application. Separating the two into their own classes is not violating YAGNI. Remember to not just think about "Today". Things are going to change, and separating view models from business classes gives you a buffer zone between these two kinds of changes.