Yes I never worked with large database system that requires this many inner-joins before, you have a point. Id say that there's no absolutely right or wrong on a per se basis, you can always find exceptions however unlikely they are. For this, I agree with you.
However, I do see a major difference from the multi-dimensional array code I found from that Zend framework book and the example you posted. In your scenario, there is an intrinsic constraint/barrier with the database system that the dataset must be returned as arrays and multi-dimensional arrays. In this case, you have no other way to get around other than using multi-dimensional arrays. Similarly if a PHP legacy function requires a multi-dimensional array as its argument, and that there is no other alternative for you to choose from, you are stuck with it and you have to construct a multi-dimensional array to get around with this limitation. The fact that multi-dimensional arrays are present and useful in some cases does not contradict with the fact that in general it's a bad programming practice, most of the times it's there because there's no better alternatives. In the sample code I posted, on the other hand, there are way many better alternatives than constructing a router with a 5-6 dimensional associative array, and they are more elegant, modular and maintainable. Using multi-dimensional array is probably the worst way of constructing a router object, if it has to be done this way, then either the author or Zend Framework 2's design was flawed.
Also the argument of development time/cost is quite controversial as well. Using a specialized object for some data scenarios will help for a project that is expected to grow in time with new features being added and old features being maintained. If you work on freelancer projects in which each task is once-and-done, you probably do not need to worry about that. Nonetheless, for many projects future insights of design are important. Using arrays may be easier and faster to launch the initial product, but extending the application and fixing bugs will be harder and more time-consuming(sometimes even impossible without big refactoring). It's about development vs maintenance costs, its about present and future costs. it's a tradeoff you will need to make, while my personal experience tells me that long-term planning tends to win out in most circumstances, at least for what I've worked on. Sure I've been in situations that the project/task is rushed, that happens all the time in college era when you are required to write a matlab program assignment that is due the following week. At times like that you'd hardly worry about quality, but its not the same story when we are talking about enterprise application design/development.
Sure our perceptions differ when our experiences differ, but I do believe that there are some certain programming practices/rules that must or at least should be enforced except in extreme circumstances. I did not say that you should never use PHP native arrays, there are times you have to live with it, especially with PHP's built-in functions that accepts or returns arrays, there's no way around that. Nonetheless, I do believe that PHP native arrays should be used sparingly, it's not supposed to present a complex structure that is better suited in object composition representation. Even with the multidimensional array database system you brought up, you only use the multidimensional array for retrieval of information from DBMS. After obtaining the multi-dimensional dataset, you will create domain objects to store and manipulate the information. In this way, you are indeed using multidimensional arrays sparingly, you use it when you have to use it.
Sometimes a script is badly designed since the coder is rushing his/her time, but in many occasions it is because they are not good programmers. Take the application I am currently working on as an example, I took it over from an original owner who initially wrote the program in procedural spaghetti code. I wondered why the script was designed this way, turned out that this was all he was capable of. I am pretty sure many posters on this forum are just like that, which is why I'm trying to bring up OOP and good programming practices. Sure advanced coders like you dont need to listen or learn, but I believe it will help beginner coders. If they are working on projects with an intense schedule, they are free to just ignore the advices, since all they care about is an exact answer to a particular problem. But if they are ever interested in improving their skills in a long run, these will come in handy. I assume most newbie posters come here to learn, not just to wish for an answer to their upcoming urgent programming tasks. Feel free correcting me if this assumption is wrong.
I apologize if I sound intense, I am just trying to prove a point and I respect your knowledge and experience.
Hall of Famer