In my opinion the lack of understanding of transactional consistency & isolation models... as well as the lack of understanding of the virtues of the relational

In my opinion the lack of understanding of transactional consistency & isolation models... as well as the lack of understanding of the virtues of the relational model... are why microservices have become such a plague and why many applications are burdened with extremely high (non-intrinsic) complexity. And I think that can be tied back to people not taking reasonable DB courses in school, or having that emphasized in their careers. The former causing people to not be properly concerned with data consistency (and doing stupid things like service-level joins). I've seen outright data races, consistency issues, odd behaviors... from systems backed by an RDBMS... because the devs just don't get or care about databases. The latter with why OOMs and "DAOs" and "transfer objects" and treating the DB as a "persistence" layer have become the default in how things are built. Many people resolve the famous "object relational impedance mismatch" by just completely abusing the database, and not thinking in a relational fashion when modeling their application and schema. I started my career with this mentality, because OOP was the rage, but came around to a POV where I learned to love the relational data model, and to start from modeling the data as the foundation. (when I still worked on data driven apps, I'm in embedded now). The classic "Out of the Tarpit" paper is relevant here.