I'm a software developer, and most companies I've worked for are organized in a system that is a middle ground between functional and matrix. Much more functional than matrix, indeed.
The structure is something like this: there are several teams in the company, each one being responsible for a specific function. But one of these teams has a special characteristic. It is also responsible for a product and works in a project-oriented manner. Let's call it the "product team". All projects that this team carries out are intended to maintain or improve their product. As such, the product team is the project "driver", so to speak, requesting services from the other teams as needed. In general, the product team is responsible for programming functions, and requests services from Data Analysis, DBA, User Interface, Test, Deployment and so on.
Honestly, from my personal experience, I have only seen problems with this approach. To list some:
Individuals in the "service teams" lack long-term commitment to the product or the project. Their mindset is to finish the service as quickly as possible and, once delivered, it becomes somone else's problem. Obviously, this is not their fault. They are only reacting to incentives, because if they do otherwise, they will probably be punished (or, at least, not be rewarded).
For the same reason as pointed out in the previous item, the service team members lack contextual information that would help them to see the big picture. They may be able to perform their services well, but they are not able to suggest alternatives or challenge wrong assumptions. Hence, the overall performance is sub-optimal.
Since the activities are inherently coupled to each other (the separation into functional teams is somewhat arbitrary and artificial), some problems are faced over and over by different teams, as the project evolves. Each team will have to learn the business rules from scratch, for example, and will probably have the same basic questions, which will demand the same basic answers. All teams will go through the same learning curve.
From a management perspective, coordinating the schedules of all those teams is a very hard problem. It is very common to have to wait some weeks to get a job done because the members of some service team are all busy fulfilling requests from other teams.
Depending on how the teams are partitioned, sometimes different teams have conflicting goals. For example, a good project team will have a high throughput (let's say, number of software features per month), which necessarily leads to changes in the production environment. The deployment team normally has the opposite goal: to maintain the production environment as stable as possible. So, they will create all kinds of obstacles to the deployment of those features.
A certain "tribal" behavior emerges from this setup. Probably this is just human nature, but when people are separated into different groups with conflicting goals, they will start to see each other as rivals and not as co-workers.
[edit to include another problem I remembered] Due to the arbitrary nature of this kind of partition, some problems that are experienced by one team can only be solved by another team, either for technical or political reasons. But such problems may be evaluated differently by each team. For the one that has the problem, it may be top priority. From the "solver" point of view, however, it may be less important. As a consequence, it will never be solved at all, or it will generate an enormous level of political conflict between the involved functional areas.
Despite all the drawbacks listed above, this kind of team organization seems to be overwhelmingly common. Why is this? Is there some big, obvious advantage that I'm missing, that surpasses all the problems I pointed out?