There is an argument that you can always add features to the sprint, so you start small and then extend sprint with additional task. But it does not work, because tasks seem to take all the time that was planned for them.
However, the rituals of SCRUM like retros and groomings taking place every 2-3 weeks is a good thing. It's like hygiene.
If your QA specialists aren't essentially developers specialising in writing test code then they probably don't belong in a modern development team.
Dedicated QA folk are redundant! The devs write automated tests for all the code they submit. It's 20 years since I spotted a dedicated QA person in the wild.
Anyway, the same happens for any multi-phase cycle. Like with code review. When there are dependencies between people, you are going to need extra items to work on while waiting, and this fights with the requirement that everything should be done at the end of the SCRUM sprint.
shift-left (aka put all of the work on the developer)
When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ?
It seems to me that this forced synchronization is just pointless and harmful.
Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in testing, this is done. It's expected that almost everything spans more sprints.