I would say that there are real technical issues behind it. The Ruby implementation (at least ruby 1.8) is not designed for concurrency : ruby 1.8 has a global interpretor lock, and it uses green threads instead of OS native threads.
So, for a web application to scale, you have to run multiple ruby interpretors, and make them work together.
Note : I am not into web development, and It's been a long time I haven't used ruby. Maybe ruby 1.9 or JRuby don't have these issues. Maybe the global lock is not a real problem for scaling up.
C. J. Date goes into detail about this in Chapter 7 and Appendix B of SQL and Relational Theory. You're right, there's nothing in relational theory that prohibits an attribute's data type from being a relation itself, as long as it's the same relation type on every row. Your example would qualify.
But Date says structures like this are "usually--but not invariably--contraindicated" (i.e. a Bad Idea) because hierarchies of relations are asymmetric. For example, a transformation from nested structure to a familiar "flat" structure cannot always be reversed to recreate the nesting.
Queries, constraints, and updates are more complex, harder to write, and harder for the RDBMS to support if you allow relation-valued attributes (RVA's).
It also muddies database design principles, because the best hierarchy of relations isn't so clear. Should we design a relation of Suppliers with a nested RVA for parts supplied by a given Supplier? Or a relation of Parts with a nested RVA for suppliers who supply a given Part? Or store both, to make it easy to run different types of queries?
This is the same dilemma that results from the hierarchical database and the document-oriented database models. Eventually, the complexity and cost of accessing nested data structures drives designers to store data redundantly for easier lookup by different queries. The relational model discourages redundancy, so RVA's can work against the goals of relational modeling.
From what I understand (I have not used them), Rel and Dataphor are RDBMS projects that support relation-valued attributes.
Re comment from @dportas:
Structured types are part of SQL-99, and Oracle supports these. But they don't store multiple tuples in the nested table per row of the base table. The common example is an "address" attribute which appears to be a single column of the base table, but has further sub-columns for street, city, postal code, etc.
Nested tables are also supported by Oracle, and these do allow multiple tuples per row of the base table. But I am not aware that this is part of standard SQL. And keep in mind the conclusion of one blog: "I'll never use a nested table in a CREATE TABLE statement. You spend all of your time UN-NESTING them to make them useful again!"
Best Answer
The relational model was first formulated by E.F. Codd in 1969, and was first implemented in various IBM databases in the '70s. It also looks to me like the first edition of C. J. Date's seminal "An Introduction to Database Systems" was published around 1974.
I was hearing noise about relational databases in the 80s, without even paying much attention. Oracle, Ingres, and Informix were all shipping server-oriented commercial relational databases in the early 80s and doing quite nicely at it.
As for when relational databases were widely used on microcomputers,, well... that's another matter. The most popular microcomputer databases back in the 80s were decidedly not relational - this would include dBase, FoxPro, FileMaker and Paradox.
I would say the transition toward relational databases on microcomputers generally occurred during the 90s, as the ability to network to relational databases hosted on servers became common. It certainly did for me - at the beginning of the decade, I would look rather blankly at people who mentioned relational databases, and by the end of the decade, I was frustrated at having to work with FileMaker (as opposed to Informix, Oracle, or MS Access) because it wasn't sufficiently relational and didn't support SQL.