And any sane ORM will perform the joins in the database by default.
Joins were good for the smaller websites, but they don't scale. By avoiding joins, you have shared-nothing models that can be partitioned horizontally aka sharding.
Now true, the latest and greatest databases such as CockroachDB go out of their way to try to do joins for you across partitions, even in an ACID manner, but then you have to use those. Better to avoid joins in the DB and do it in the app. You can then use a graph database instead of a relational database, going from O(log N) lookups to O(1) lookups for related data.
Oh and finally, the newest (and pretty cool) craze of BFT, Byzantine Fault Tolerance. You can't achieve that if you're doing joins across different publishers, because they're not supposed to be able to access each other's stuff "just like that".
Our ORM supports joins, even with multiple indexes, it even lets you define relationships and figures out the joins FOR YOU, but it is discouraged if you're building scalable sites.
By the way thank you for proving point #6 hehe1) Get the root record(s) from id(s)
2) See what related records it needs, combine them into a list of ids, partition list by shard
3) Ask each shard for the corresponding records
4) Repeat from 2 if necessary
5) Return this whole tree / graph to the user
Graph databases can do this in O(1) instead of O(log N) lookups.
Relational joins are just one way to achieve this, which can be made atomic in the ACID sense.
However, as you scale up your website, eg with 100,000,000 users, it would be silly to do massive joins. Google even says this in their docs now, for BigQuery.
Instead, design your systems from the beginnig to be as parallel as possible, if you think they will scale.
Look at the problems with Ethereum for example. Or Twitter fail whales of the past.
The relational model was designed to address the limitations of the network/graph database, especially to allow arbitrary (ad-hoc) querying and to decouple the physical storage from the logical model. But if you don't need all that, a graph database may be fine.
https://blog.acolyer.org/2017/07/07/do-we-need-specialized-g...
For the vast majority of use cases regular SQL databases blow graph databases out of the water. Unless you go for graph-specific algorithms like Shortest Path, and even then...
Most sites do not have to scale beyond this limitation (or can use database followers to throw a bit of money at the problem). Providing Google as an example is a bit exaggerated as almost nothing in the world has the scaling needs that google has.