What's the difference with prioritizing tickets in a Kanban queue?

In the end it's the work of the PM in both cases.

People with enough power in the org will insert their ticket in your precious sprint anyway.

If you're going to constantly groom your backlog to maintain priority order that is fine, but that's more work than maintaining a partial order. In fact, scrum is even less work than a partial sort; it just says "we're going to work on your ticket in sprint X" without being more specific.

Cycle time on a board gets you that as well.

This provides more visibility and granularity, increasing confidence and satisfaction of customers.

How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.

Scrum informs the customer that their ticket will be processed in the next sprint or not. It gives visibility into the future. A Kanban backlog, which is unordered, only tells them if their ticket is being worked on now.

Putting a ticket into a sprint is the same as putting it into a queued stage of kanban for purposes of reporting, although the reported number will differ (“this sprint” vs mean cycle time with percentile bounds.) Both methods can have unordered backlogs where something can sit indefinitely.

(Many orgs are understandably nervous to automatically report a simple number as an estimate; in those cases, you could translate cycle time into a date range estimate so long as you’re not also expected to report “we’ve started” etc. since those won’t necessarily line up.)

It provides less granularity and visibility, but it provides regular, well-defined touch points.

OTOH, nothing stops you from having biweekly reviews with customers in Kanban, or delivery goals on the same cycle that guide decisions of which work items to pull in and whether to allocate more effort or defer ones that run into unexpected complexity. There’s no reason to (and plenty of reason not to) build a work-should-end and then new-work-items-should-start cycle around that; continuous flow makes more sense.

A kanban with periodic commitments to the next batch of tickets to be worked on is functionally scrum to me.

Even in Scrum, a Sprint Goal is not a batch of tickets, and for kanban the period re-evaluation of goals/priorities can be even less like that. And, of course, a review can be whatever there is to review.

What I am saying is that, insofar as cyclical touch points are a valuable customer-interaction feature of Scrum (and even when doing “proper Agile” with daily interaction with the customer as part of development, which is more an exception than the rule in most “Agile” places I’ve seen, the fact that “the customer” is usually an organization and the ideal daily interaction is individuals at the working level, not whole-team-to-whole-team level, those periodic touchpoints are useful) you can have them in Kanban while maintaining continuous flow as opposed to sprint-oriented flow in the development team.

It would be amusing but I've never been told to wait until the next sprint when contacting customer support.

Customer support is one kind of a service. I was thinking of something like a platform team, which creates complex tooling for other teams. I don't know if you were just joking, but I thought I'd clarify.