Ø        The relational model can handle hierarchies with ease. 

I'll give the SQL DBA's out there a moment to clean up the coffee they just spat over the keyboard......

RM gives you multiple ways to do it.  Adjacency list, nested-set, fixed level or just stuff the whole model into a data type ala XML.  RM "prefers" the  adjacency list as it has an operator just for it. "Transitive Closure" or TCLOSE in geek parlance.  The introduction of CTE's in SQL Server 2005 helps resolve some issues for "walking the tree" but comes with several gotchas that are not immediately obvious.. Be careful...

Ø        It supports n-dimensional data structures. 

I'll give the data warehouse people out there a moment to clean up the latte they just spat over the keyboard......

 Because it can be represented in a "rows" and "column" fashion (ala spreadsheet), people routinely infer that it has only 2 dimensions (rows and columns).  That is incorrect.  Roughly speaking, each column is its own dimension.  A relation (table) without dimensions (no columns) is possible and is quite useful.  What about a relation with infinite dimensions? I don't know... "Cubes" are puny 3-dimensional structures in comparison. :-)

Ø        5NF is fairly easy to achieve in practice.

I'll give the performance freaks out there a moment to clean up the energy drink they just spat over the keyboard... 

A good DBA will push hard for 3NF in practice and will be pleasantly rewarded with excellent performance for a majority of the actions thrown at.  Normalisation is more about constraints and dependencies in your model than just "adding more tables".

If all your relations (tables) contain single column primary keys and you are in 3NF, then you are AUTOMATICALLY in 5NF.  If the only composite keys you have are in "junction" or "link" tables (many to many) and those tables are not FK'd to other tables, then you apply as well for 5NF glory.  4 and 5NF concern themselves with composite keys and join dependencies.  Basically, if you have bothered to get to 3NF, it is very little extra work to get to 5NF.

6NF is another matter entirely…

Ø        You cannot update a tuple (row).  

I'll give the middle tier developers out there a moment to clean up the cola they just spat over the keyboard...

In RM, a tuple (row) is a value and values can never be updated.  Don't get confused with variables.  We don't update tuples we replace them.

This translates to a DELETE then an INSERT in SQL speak.  The SQL shorthand of UPDATE can cause the DBMS to do one of 2 things: physical Inline update or a physical delete and then physical insert operation.

Ø        The relational model handles arrays, lists and complex types with ease. 

I'll give the OO "database" people out there a moment to clean up the urine they just spat over the keyboard... 

The original outline of RM required that a data type (aka domain) be "atomic".  Initially this was interpreted as limiting types to "simple" things like numbers and strings.  As time and research progressed, it was realised that the word "atomic" had no formal definition and thus should not have been there at all.  Any and all types are allowed in RM.  The only restriction is that a single value of that type be allowed in each attribute.  While this gave the model incredible power, it did present a design conundrum to the user... "One mans type is another mans relation (table)".  As an example take a postal address.  RM allows you to define this as either a type (the entire address is represented as a single value in a column) or as a relation (table) with several attributes. 

The introduction of CLR UDT's in SQL Server 2005 is a step in the right direction, but without data type inheritance, the practical uses for them diminish...