Dedicated Resource Model generally only works if there are always a significant number of projects going on, but software development is a fairly common example of this model. Each new product, and potentially each new release is a major project, so the concept of having dedicated resources for projects can work well. That doesn’t mean that every project uses exactly the same team – there will be differences in the weighting of front end vs. back end work which will change the balance of each team slightly, but in principle the PMO controls all project resources – allocating them across initiatives, monitoring skills shortages and addressing training, etc.
Here’s main problem with this model – it’s structured more for the benefit of the organisation than for the individual. In some ways you can mitigate these risks by cycling people through support and maintenance roles on the product that has just been released, but that has its own challenges – staff who have just spent months working on leading edge development for a new piece of software may not be thrilled at going on to a role of dealing with help desk tickets.
From a corporate side the argument against dedicated teams is that functional managers lose control over resources – handing it off to the PMO and the PMs.