Leaving a team to "Do Their Own Thing"
This is actually the best place to start this conversation. Software isn't developed for its own sake. It is also rarely developed in a vacuum. Therefor, a team must operate in a way to provides value to the customer frequently and also in a way where they can collaborate well with other teams and the rest of the organization. Teams should always be improving how they work and looking for better ways to create value in the organization.
Does it have to be Scrum?
No, absolutely not. In fact, sometimes Scrum is the wrong choice. Support centers are probably the easiest case to see. They are more about the flow of work and approaches like Kanban are better suited. However, even in other approaches, the focus is still on value delivery and constant improvement.
Do you need a Scrum Master or other type of team coach?
The simplest way to look at this is sports teams. Can a baseball team function without a coach? Sure. They'll be missing an important perspective and may have trouble making improvements that other teams would find easy with a coach, but they'll play the game.
Software teams are exactly the same. No Scrum Master or team coach will still get you working software. A part time coach will get you some improvement. But a full time Scrum Master or coach should pay for themselves in improvement many times over.
Getting Team Buy-in
A better way to ask this question is: Why should the team care? Why don't they now? If they aren't producing working software and no one calls them out on it, then why should they change. If the organization doesn't celebrate improvement, then why should they put the effort in? Alternately, if they are constantly improving and they are delivering value, maybe they've already solved the problem and the rest of the organization has something to learn from them.