I'd diagnose the core problem differently, however. What application and system developers care about in modern architectures is application level correctness from the perspective of the client (customer, tester, etc). What a lot of the research is interested in is isolation within the context of a single database. That's a useful building block, but doesn't compose into end-to-end correctness in ways that most application architects and developers can reason about as soon as the application spans multiple stores (because SoA, or because microservices, or because it interacts with a SaaS, or whatever).
So application builders are left with the problem of not being able to reason about how to build correct applications, and not having the tools to build those applications correctly, and so end up settling for some level of weird behavior under concurrency. Turning up the database isolation level may hurt performance, but does little to rein in the overall incorrectness, so there is little motivation to do it.
If the database research community wants application developers and operators to care about isolation more, I suspect that we need to care more about atomicity, isolation, and consistency "in the large". Think more broadly, across whole microservice or SoA architectures, and provide ways to give customers ACID properties end-to-end, and ways to compose databases, services, and systems that preserve these properties.
That doesn't mean that per-database or per-component isolation isn't important. It's practically important, and there's good research on the effect it has[1]. The problem is that its not sufficient, and so folks feel less motivated to pay the (perceived) performance costs.
For folks who'd like to understand isolation levels better, I'd recommend starting with "Seeing is Believing" (https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf) and "A critique of ANSI SQL isolation levels" (https://www.microsoft.com/en-us/research/wp-content/uploads/...) both of which do a good job explaining the differences between levels in a way that isn't tied to implementation.
[1] One good paper there is "ACIDRain: Concurrency-Related Attacks on Database-Backed Web Applications" (http://www.bailis.org/papers/acidrain-sigmod2017.pdf).