I guess I wasn't clear enough. Certainly the idea predated Rails, but I think the heavy insistence you see pretty much everywhere on segregating them probably came from Rails.
“Multi-tier architectures are characterized by the separation of the user interface, business logic and data access logic. Many organizations are implementing multi-tier architectures for enterprise applications to realize the two key benefits."
1996, and I am pretty sure this marketing speak page reflects what had already been being talked about in the industry for quite some time.
I think the more frequent discussions of separating domain logic from persistence in the context of Rails is a simple result of the fact that Rails is an opinionated framework whose basic structure promotes the exact opposite of that good practice, to wit, implementing the domain model not merely tightly coupled to the persistence layer, but indistinguishable from it -- in that Rails models provide both the domain model and the persistence functionality. So you see a lot of talk about basic separation of concerns in the context of Rails, because Rails so strongly leads people away from it.
This certainly has a certain kind of pragmatic value in getting something simple functioning quickly, its not just simply bad design of the framework. OTOH, it has the potential to impose a legacy cost as the complexity of the application increases.
