Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet".
In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever.
If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.
I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time".
I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
I develop internal tooling for a b2b company, and we ship features multiple times a week. Much of that is backend.
Often not huge features, but still features that make life easier for colleagues.
Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.
If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.