This is one of the main benefits I see of a "service" abstraction - be it a networked microservice or just a class that encapsulates some core business logic. A lightweight layer for reading and writing the DB.
A big reason this is useful is that in any large system those updates are likely to be denormalized in some way - a write to the DB may also need to also invalidate a cache or refresh a separate search index. So all updates should share a codepath.
And for reads in a large system speed is crucial. It's much easier to avoid pathological query performance if reads are all made through some kind of getPostsByIDs method that knows how to efficiently batch queries and uses optimizations like Django's select_ and prefetch_related
For smaller projects (especially proofs of concept) I go entirely the other way: the smallest amount of tightly coupled code that can illustrate the desired result. Knowing when to architect for scale (both in traffic and the size of the maintenance team) is art, not science
