TLDR
You should be using your Retrospectives to fix problems in your process and keep it aligned with good business outcomes, not dogmas.
So ...
- Be open and honest in your Retrospectives.
- Don't forget: The point of any business process is to keep the business profitable. (Securing your job in the process and furthering your career are often bonuses.)
Firstly, if you have concerns that the process is not effectively utilizing the resources on the team, you need to mention it during the retrospective. The "agile" processes have retrospectives precisely to address problems with your current process. If members of your team are not being utilized effectively, it may be beneficial to the business to use them differently, so raise the issue. Maybe you need longer sprints to fit more sophisticated projects into the sprint. Maybe you need to back off the "commitment" mentality with sprint items. Maybe you need 10% time, and up to 20% or 40% time for senior or lead level members. Etc.
Secondly, don't forget the purpose. The purpose of agility is to utilize programmers efficiently and predictably. It is not to primarily to make developers feel good or further their careers. Only to the extent that these align with the business outcomes is it worthwhile to pursue them. ... If they are misaligned with business outcomes, these "great developers" need to find work at companies that actually benefit from having "great developers."
Many of us work for companies where "great developers" can make a serious, long term, positive impact on the business. In those companies, using these folks effectively is part of the discussion in and above the team. This often means their outcome for a sprint is often a document or a POC instead of a feature. It means they do a lot of code reviewing and mentorship. Etc. ... And if I'm being brutally honest, when the truly great developers on and around my team make a two week commitment to deliver a complex feature, they don't complain; they get it done.
But, we also just recognize that Scrum is a framework with a purpose, and part of that framework (as is true with any good framework) is adaptability. We explicitly adapt to the the team makeup and the business outcomes we need to deliver.
Other companies don't always benefit from having "great" developers. Most of the contract shops I've worked with, for example, have had better results by churning out near copies of other projects. Others, with really smart folks on the team, have struggled to meet deadlines for basic functionality. "Great developers" are not a great fit when the work is not at all complex. They're a actually bad for the business if they don't find their own way to align their creative genius with business outcomes -- the business is usually perfectly healthy without them.