How does the philosophy of trying to decouple the persistent storage implementation from the rest of your application fit in with lazy loading? (You cannot determine when you want something initialized without some business logic.)

Apparently, since no one can answer this, they are mutually exclusive and so lazy loading does not follow the best practices as specified through standard design patterns.

Why are we having this anti-best practices approach sold to us?

The idea is to have all business code within the scope of a transaction / Hibernate Session, so that in effect lazy exceptions would not be an issue. However this requires significant thought when designing an architecture and is not always possible. In any architecture where detached objects are present you'll eventually have to solve lazy exception issues, either by eagerly loading whatever is necessary before detaching the objects, or otherwise by having some sort of rule which you obey throughout the app so you know whether you have the data available or not. It's not easy. But no one said enterprise architecture is easy :-)

But then you are not decoupling persistant storage, which is supposed to be an important design pattern.
Your persistance code is embedded in your business logic, or vice versa.
So by using lazy loading, you are breaking one of the main tennants of design patterns.

Running all business code *within* a Hibernate transaction/Session doesn't necessarily mean that your business code needs to be aware of this fact. This can be easily achieved with AOP using Spring or AspectJ. Thus, coupling is not an issue, and becomes more of an implementation/configuration detail.