Not all databases use relational algebra. Among other things document databases are increasingly common for a number of types of applications and ORMs can provide good experiences for those types of databases as well.

Beyond document databases, I think the "theoretical" mismatch between OOP and Relational is often over-exaggerated/over-stated and most of the mismatch blamed entirely on the wrong direction. For historical reasons, some of which were a love of relational algebra mathematical "purity", relational databases have tended to have problems storing and querying hierarchical and graph data. Hierarchical and graph data are relatively common and somewhat "natural" in OOP: inheritance and polymorphism often rely on hierarchies, and references between objects can easily be complex graphs, including cycles and other complex graph mechanics.

Theoretically "pure" relational algebra cannot accommodate that kind of data, it's what keeps the math simple and pretty. There is a clear OOP/Relational mismatch, but it's a lot more to do with that theory problem, and the problem is entirely on the relational side being unable to express practical, common, complex data. If there's something holding things back and enforcing "mediocre schema design", there's a lot of fingers to point at relational algebra itself (and SQL too, for its own ways of trying to be "pure" to relational algebra).

In practice, of course, there is no such thing as a "pure" relational database that people actually develop software for and most SQL databases have all sorts of "impure" extensions and tools and some dialects of SQL can surely feel quite powerful but still often have real, interesting holes in the types of data they can describe and query. Though some of those extensions offer escape hatches today, with the increase in JSON support especially in the majority of SQL databases.

I know in practice I've anecdotally been seeing an increasing number of cases where ORMs remain relevant and helpful but reliance on SQL-based databases and SQL specifics is diminishing all the more each year. Not that I don't think SQL-based databases are bad at what they do, what they do well they do well, but that there increasingly there's a lot more escape hatches being used to non-SQL data stores (even if just increasing numbers of JSON blobs in an SQL database). There's always more hierarchical and graph data to store and query, and there are better options every year for that kind of data.

From my perspective, the best ORMs often don't "abstract" away the relational underpinnings of a relational database: they do their best to help you simplify (if not dumb down) your application's intended data structures to better fit a relational database. I say that as someone with good SQL performance understanding, a love of the theory of pure relational algebra, and a knowledge that when I need to that I can absolutely beat an ORM at hand tuned SQL and "brilliant" relational database schemas. I'm sure our experiences have been vastly different to this point in our careers. I agree with you that there is an ORM/relational mismatch, but I don't expect you to agree with me that my practical experiences continue to tell me that the fault isn't with ORMs in that mismatch.