I would probably consider consultancies very differently from product companies.
Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.
I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.
Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.
In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies).
The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.
However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.
Interesting on that first point, that's not what i would have expected. So what are you seeing from these product-minded engineers that leads them to choose a consultancy over a product company?
For "underdog" consultancies, i've always felt that they win by
1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.
2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.
Both 1 & 2 are valid strategies for underdog consultancies. Consultancies that are very good at #2 may also have better ability to keep people, who are exceptionally good at some specific tech or domain, because they usually have higher rates and peers that are good at the same thing.
As for product-minded engineers, there is often more freedom at a smaller a consultancy than in (many) product companies. You can switch projects every 3-18 months, select a new technology you want to learn, have big ownership on the helping the customer building the product, etc. To some people this is ofc a downside and a lot depends on the kind of client/project you're working in. Much of this also is lost, when the consultancy starts taking on bigger projects with bigger clients that already have much of these things set in stone.
Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.
I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.
Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.