If you were the guy getting hit from 20 different people, each with their own emergency, has to be done now, $4 million deal counts on it BS task, I wager you'd be singing a different tune. Oh and come to find out, that $4 million dollar deal? It had fallen through the previous month only no one had communicated it to the person makeing the request.

My favorite was the marketing manager who thought an email, with a full size image attachment, and note saying 'this needs to go on the marketing site' was sufficient requirements.

Requirements and prioritization are not a bad thing. Excessive bureaucracy is.

  Both were just teams of obstructionists.
  "Oh you need something today?
    ... get a jira ticket made 
    ... work assigned out next month."

It is possible that you might have a different opinion of the situation if viewed from their perspective. It's likely not deliberate obstructionism, but rather them trying to triage the requests so that they can be most effective across all customers. (It's possible that your ops team did not adequately communicate this to you.)

In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important.

Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.

This is a good point, but it's a sign of dysfunction. I've seen the case when 50% of the issues are "P1 highest priority" (and most of them forgotten in a week or two). People making requests need to get some idea about what development effort (and maintenance!) costs. I don't know a good way to do this, except to be in a very small company.

Tickets at least require things to be documented, which is the biggest problem with ad hoc devops.

Sounds good. Does your company hire remote? :)