Have you considered limits with degraded experience? For example you might have a map with real-time-synced pop-up annotations, and someone puts too much stuff in there, and things gets too slow.
So you add the rule that text over X KB should be hosted elsewhere, and your nice real-time-map only gets a link to it - and that "elsewhere" is much simpler. Maybe it's a wiki page without collaborative editing support. Or as a more extreme version, you have to compose everything on your computer and upload a whole .txt file at once. Something that would be relatively simple for you to implement.
This way huge-text users would still be able to work, albeit with more effort... and yet everyone else would be able to enjoy fast experience.
I'd say hard limits, the ROI of those users makes it uneconomical to support them.
> how do you handle super users?
You did not indicate whether this is a "free for use" app. or a paid app. The answer differs depending upon this fact.
> It certainly makes me think about algorithmic complexity every day.
Realistically you should be thinking about this anyway to some extent for anything much beyond quick one-off's to get a sub-task done in a larger task.
> Should I just put my foot down at some point and say "no, actually here's hard limits X, Y, and Z"?
My opinion, no. It would be fine to say something like "above X amount, you (may|will) find performance may be reduced" but don't add hard limits.
> Or just suck it up?
Are the users paying for the app? If so, then generally you will likely want to do so, otherwise you'll likely lose your best users.
Is the app free for use -- if yes then also feel free to say "yes, that amount of usage is going to cause problems, I'll work on it when I can, but 'real life' means I have little time to do so..."
> These users are great at surfacing bugs that would've affected everyone eventually,
Which is one big reason not to alienate them with things such as "no more than 1000 X's allowed". Most of them should be understanding of "no time right now for fixing that, it's on the list" (provided the app's free). If the users are paying, that's a different story.
Another option you might consider, in the "pay" scenario, is a somewhat higher cost for extreme usage situations to help cover your time investment in supporting those extreme usage situations.