The Alpha/QUEL linage chose relations, while SQL went with tables. Notably, a set has no ordering or duplicates — which I suggest is in contrast to how the layman tends to think about the world, and thus finds it to be an impediment when choosing between technology options. There are strong benefits to choosing relations over tables, as Codd wrote about at length, but they tend to not show up until you get into a bit more complexity. By the time your work reaches that point, the choice of technology is apt to already be made.

With care, SQL enables mimicking relations to a reasonable degree when needed, which arguably offers the best of all worlds. That said, virtually all of the SQL bugs I see in the real world come as a result of someone not putting in enough care in that area. When complexity grows, it becomes easy to overlook the fine details. Relational algebra and calculus would help by enforcing it. But, tradeoffs, as always.

>SQL [...] is a database language [...] used for access to pseudo-relational databases that are managed by pseudo-relational database management systems (RDBMS).

>SQL is based on, but is not a strict implementation of, the relational model of data, making SQL “pseudo-relational” instead of truly relational.

>The relational model requires that every relation have no duplicate rows. SQL does not enforce this requirement.

>The relational model does not specify or recognize any sort of flag or other marker that represents unspecified, unknown, or otherwise missing data values. Consequently, the relational model depends only on two-valued (true/false) logic. SQL provides a “null value” that serves this purpose. In support of null values, SQL also depends on three-valued (true/false/unknown) logic.

Or, in other words, "relation" does not mean the relations between the tables as many assume: the tables, as a set of tuples, are the relations.