I don't think the main use case for service layers is to be able to some day replace the ORM, but instead to have a place to put logic that should happen in your application despite a record is created or not.
For example, suppose you want to index in ElasticSearch a blog post on creation, but only if it's state is published and after doing this, then send an email to all your users, etc. Where would you put all of this logic? Models can get pretty big even if only they have to call other modules for performing these operations.
I'm currently working on a complex business-heavy application where we apply DDD and other "enterprise application patterns". Most of the negative aspects in the article I see proven during my daily work (like re-implementing parts of the ORM within a repository).
Even then, as I understand this is the approach as its described in DDD books and "classics" like "Enterprise application architecture".
I have also worked with the opposite way as described in the article - mixing business logic and Django specific code and saw it becoming a hard-to maintain mess quickly, where it was hard to see the business logic between all the infrastructure code.
For me the hard thing about "Enterprise Python[Django]" is to find a way how we can apply these enterprisy architectures in a more Pythonic way.
Hopefully there will be more books and articles about these topics now that Python gains more and more momentum and starts to become more respected to implement heavy business driven applications.
For example, suppose you want to index in ElasticSearch a blog post on creation, but only if it's state is published and after doing this, then send an email to all your users, etc. Where would you put all of this logic? Models can get pretty big even if only they have to call other modules for performing these operations.