Oracle (and DB2) have had multiple nodes for decades, with support for referential integrity and transactions across nodes. I guess perhaps you are talking about geographically distributed nodes that have slow pipes between them?
But in any case, yeah, there's a bizarre tendency for humans to want to latch on to hard and fast rules. I've heard things like "don't join more than 3 tables together", and you encountered at your workplace a rule that sql updates should only affect a single row at a time. Many workplaces have such farcical restrictions, resulting in behaviours like the allegorical monkeys in the room (https://workingoutloud.com/blog/the-five-monkeys-experiment-...).
My theory - small children go through a phase where they love to know what the rules are and they love to set down rules for others. Some people never grow out of that, and they hold a worldview where everything would be OK as long as everyone followed the rules. And if for some reason that didn't work, then all you have to do is to add some more rules. Such people may not be the most creative but they cling fiercely to their rule-based approach to life. Since it's always easier to add rules rather than remove them, a poorly managed organisation can find itself trussed up tightly in these rules and an all around rubbish place to work where everything takes forever.
While that covers the prevalence of rules such as "no SQL statement may update >1 row", you also ask why people may tend not to use features such as referential integrity in avant garde databases such as Spanner et al. Personally, I would avoid using such features if only because they are so challenging to engineer and are likely to contain bugs for a few months or years as they are bedded in. That's especially true once a system is under heavy usage and the impacts of any issues are enormous. It's easier to just keep on doing whatever you are already doing.
> ...multiple nodes for decades, with support for referential integrity and transactions across nodes...
By definition, that would mean relying on something like two-phase commit. You're essentially running on a single "node" that just so happens to be physically dispersed across multiple machines, since the system would become partially or totally unavailable if the nodes can't communicate with low latency.
But in any case, yeah, there's a bizarre tendency for humans to want to latch on to hard and fast rules. I've heard things like "don't join more than 3 tables together", and you encountered at your workplace a rule that sql updates should only affect a single row at a time. Many workplaces have such farcical restrictions, resulting in behaviours like the allegorical monkeys in the room (https://workingoutloud.com/blog/the-five-monkeys-experiment-...).
My theory - small children go through a phase where they love to know what the rules are and they love to set down rules for others. Some people never grow out of that, and they hold a worldview where everything would be OK as long as everyone followed the rules. And if for some reason that didn't work, then all you have to do is to add some more rules. Such people may not be the most creative but they cling fiercely to their rule-based approach to life. Since it's always easier to add rules rather than remove them, a poorly managed organisation can find itself trussed up tightly in these rules and an all around rubbish place to work where everything takes forever.
While that covers the prevalence of rules such as "no SQL statement may update >1 row", you also ask why people may tend not to use features such as referential integrity in avant garde databases such as Spanner et al. Personally, I would avoid using such features if only because they are so challenging to engineer and are likely to contain bugs for a few months or years as they are bedded in. That's especially true once a system is under heavy usage and the impacts of any issues are enormous. It's easier to just keep on doing whatever you are already doing.