Exactly. The idea that you have to sacrifice the right abstraction for the sake of performance is preposterous, and can only be explained by lack of imagination.

Just because most SQL DBMSes happen to implement relations, foreign keys, aggregates, etc. in a specific way, it doesn't automatically mean that the specifics of these implementations must be elevated to the status of laws of nature.

SQL DBMS are not relational, so they don't really implement relations (they support bags and NULLs), not all their operations preserve closure, have weak support of relational constraints, of physical and logical independence, I could go on and on.

Problem is practitioners confuse RDBMSs with SQL DBMSs and are incapable of seeing what they're missing in terms of practical benefits of the latter.

NULL is part of Codd's articulation of the relational model, even if later theorists have proposed cleaner variants of the model without it.

Yeah, these things you mention have always annoyed me. In particular, every relation should have a primary key, possibly consisting of zero attributes. If the primary key consists of zero attributes, the relation must have at most one element, because the primary key (the empty tuple!) determines every other attribute.

Indeed, but it helps a great deal to give examples that show better ways, or if not working examples, even sketches of credible implementation ideas.