Like everything in life, analogy is just that, an analogy, it’s not an exact representation. So, when we call someone a servant leader with respect to Scrum, we’re not calling them a servant. Servant here acts as an adjective, not the noun. The person is still a leader, which implies the ability to influence those they are leading. I would argue you can do both. I think we also well know that ultimately, the noun “leader” is the more important word than “servant”, so in situations where it’s important to choose the one or the other role, the leader part usually has to win out.
In military leadership literature, there is a spectrum of leadership styles, essentially from micro-managing to laissez faire. What they tell you is that you generally want to be leading from the right of center of the spectrum (something like highly delegative), and that the rest of the styles are for special and rare occasions. I tend to subscribe to that theory.
The role of “servant leadership” as a concept, IMO, is to remind people to stay in the “highly delegative” state of mind, as much as possible, when it comes to leading. Delegate the work out to your team, and spend most of your time serving the team (removing obstacles that get in the way of their objectives).
When serving the team as the Scrum framework expert, I believe that ScrumMasters can follow the same military leadership style spectrum, if they know and understand the concept well enough. There’s a time to delegate/serve the team, and there’s a time to micro-manage the team, such as when you’re training them as newbies to Scrum concepts.
On the other hand, when the ScrumMaster is acting in the role of removing impediments that are getting in the way of the general software development process(i.e. not Scrum related), the ScrumMaster should almost always be in a servant or facilitation type role. This is because no one, not even the ScrumMaster, is allowed to tell the development team how to turn backlog items into done software.
I’ve always felt that one of the intended effects of Scrum was a way to remind those who function as software leaders to apply the same kind of leadership that the military recommends (most of the time highly delegative, the rest of the styles are for special occasions only). As my military friends remind me, though, delegation is not just a matter of doling responsibilities out — there’s much more to good delegation than that, but that’s a subject for another day.