A well thought-out post and a good read, but both of the author's points about the limitations of relational databases are a little misleading.
The first, "Every single element in a relation (aka table) has to be exactly the same type" is true in many relational databases, but isn't necessary: SQLite, for example, is implemented with a nice form of dynamic typing where individual columns can take on multiple data types.
Second, "SQL isn't even Turing-complete" is sort of a folk theorem in computer science that isn't necessarily true anymore, especially with all of the proprietary SQL dialects in existence: the original standard, SQL92, is basically equivalent to relational algebra, which has the expressive power of first-order logic - it's so weak it can't even express concepts like graph reachability. But constructs like recursive queries have been added to the SQL standard since SQL92 which may make even standard SQL Turing Complete.
AFAIK PL/SQL is not "Oracle's SQL". It's executed by a different engine and you get context switches when you execute SQL Code (don't know about T-SQL).
Second, "SQL isn't even Turing-complete" is sort of a folk theorem
And it doesn't mean anything, unless you specify its exact limitations. If they are merely theoretical limitations that nobody uses in practice: who cares?
If he wants to teach his students that grades "poison our educational environment", why is the solution to give everyone an A+? He's just using grades as currency to buy his students' support for his experiment in anarchy. I wonder how many of them would have still participated in his class if he had announced on the first day that everyone would get a C, a D, or an F?
I used to work for a decent-sized international bank that used Excel for pretty much everything (any development projects were doomed if users couldn't pull the data they produced/exposed into Excel). So I can tell you some of the things I saw people need when working with Excel in a large organization:
1. Ability to push/pull a range from a company-wide database, based on a (name,date) key. When you pull based on a (name,date) key, you get the first range with that name that was published on or before the date you specified. A dev team at the bank implemented this and people really loved it.
2. Versioning, but more for reasons of space than for having a "blame" feature. People use the same spreadsheet daily/weekly to create a report, so they have to save copies of the reports daily/weekly in case they need to reproduce the calculations from a particular report even though the differences from report to report were just minor tweaks. It wasn't uncommon for me to see spreadsheets that were > 100 MB, copied and saved daily.
3. Better explaining of formulas - you can ask Excel what cells reference another cell and it'll draw a bunch of arrows for you, but it still takes a lot of concentration to figure out why you're getting the number 4 in a cell when its references are many cells deep, spread across several worksheets. It would be nice if there was a clear way of explaining a cell's formula without having to navigate from worksheet to worksheet and actually hand-trace the references. Even collecting all of the references in one place and drawing out a tree of formulas would be an improvement.
The first, "Every single element in a relation (aka table) has to be exactly the same type" is true in many relational databases, but isn't necessary: SQLite, for example, is implemented with a nice form of dynamic typing where individual columns can take on multiple data types.
Second, "SQL isn't even Turing-complete" is sort of a folk theorem in computer science that isn't necessarily true anymore, especially with all of the proprietary SQL dialects in existence: the original standard, SQL92, is basically equivalent to relational algebra, which has the expressive power of first-order logic - it's so weak it can't even express concepts like graph reachability. But constructs like recursive queries have been added to the SQL standard since SQL92 which may make even standard SQL Turing Complete.