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."