It's funny, because I'd started using a service layer myself a while before I realised there was a term for it. The problem I had at the time was that lots of my business logic was going straight into my models. It made sense to me at the time, but it turns out that when you do this, you end up with quite complicated models with coupling between function calls all over the place.
The primary reason I started taking business logic out of my models and sticking it into separate classes (I called them "processes" at the time, because I didn't know what term to use) was to encapsulate the logic and make my models cleaner. It made a really big difference. It turns out that by doing this, you can also unit test your service objects as well, which gives you another great reason to do it.
Nowadays, my models (or "entities", because I tend to work with Doctrine a lot now) are very clean and simple - I have nothing more than getters and setters in them really now. Anything that actually uses the models to do stuff is put into service layer objects, and it's made a big difference to the cleanliness and quality of my code.
It's a good thing to do. Once you start doing it, you'll really start to see how clean your models stay, and how easy it is to isolate the logic for any given service (because that logic will exist only once, and in a clearly defined place). I'd also highly recommend unit testing your service objects as well.