I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
If testing in "real time" is not possible for some reason, the following sprint should have testing support baked in as an explicit task.
And, IME, sprints work well for mature products where there's a steady flow of defects and enhancements that are relatively easily articulated. Sprints work less well for greenfield development with new tech - you just end up with long strings of spikes/analysis/PoC work (it can still work, but you tend not to have concrete deliverables each sprint).
That’s how it works in an industry where product bugs can kill people. The devs do their own testing but there are large testing teams that take a deep look at at everything the system does.
Of course, if your project management listens to you and trusts you, you don't have this problem, so I understand your take.
Because you'll get fired if you don't...?