It is all about decoupling your app into self contained pieces, each one defined by the requirement to do one job really well.
This allows you to apply specialised design patterns and best practices to each component.
For example, the business layer’s job is to implement the business logic. Full stop. Exposing an API designed to be consumed by the presentation layer is not its “concern”.
This role of the go between is best performed by a service layer. Factoring out this specialised layer allows you to apply much more specialised patterns to each individual component.
There is no need to do design things this way, but the accumulated experience of the community indicates that it results in an application that is much easier to develop and maintain because you know exactly what each component is expected to do, even before you start coding the app.
Each layer should do one job really well. The role of go between that the service layer performs is one such well defined job and that is the reason for its existence: it is a unit of complexity that is designed in the same way over and over again, rather than having to reinvent the wheel each time, to mangle this role with the business logic where it does not belong. Think of the service layer as a mapping component. It is external to the business logic and does not belong in its classes, or in the controllers either.
Also, as a result of being factored out of the business logic, you get simpler business objects that are easier to use by other applications and services that the “business” consumes.
ASP.NET MVC is nothing if not a platform to enable you to write your apps as specialised components.
As a result of this increasing understanding of how to specialise components, programs are evolving from a primordial bowl of soup and spaghetti into something different and strange. The complexity they can address, whilst still using simple structures, is increasing. Evolution is getting going. If life is anything to go by, this has to be good, so keep the ball rolling.