After discussing some code examples from Robert Martin's books, it appears that his designs may be for a more bureaucratic Organization than the one some of us normally find ourselves in.
I tend to purposely avoid organizations that I consider overly bureaucratic, so perhaps my view of code and Robert's are shaped by the organizations that we target. It seems like he separates concepts in order to partition staff. However, such barriers create more total work in my opinion because one has to manage the extra interfaces between the barriers. But if you are dealing with developers who are perhaps not very skilled or not very motivated, then heavily partitioned code may be the way to go as far as predictability and developer progress monitoring. Large organizations tend to prefer predictable workers sometimes at the expense of productive workers, perhaps those with a tinge of Cowboy Coder personality. I get bored spending too much time managing parameter lists and pushing and pulling stuff in and out of interface layers. I feel better when the code is actually doing real work, solving the problem at hand.
I don't know if procedural/relational is as bureaucratizable as OOP. It is not something I've really cared about in the past so don't know the upper limits of p/r in that category. I try to keep my code fairly lean and simple regardless of who will be working on it. I don't partition concepts unless there is a clear need. (It is tough to partition by everything where there are multiple conflicting division candidates anyhow, which is usually the case. Martin's choices are thus somewhat arbitrary in my opinion.)
Paul Graham has made some similar remarks in his criticism of OOP. See points 2 and 3 at: www.paulgraham.com 
Excerpts:
"Object-oriented programming imposes a discipline on these [mediocre] programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication."
"Object-oriented programming generates a lot of what looks like work...Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work."
--top
See also: Yag Ni, Separation Of Concerns
See original on c2.com