The problem is when "scrum masters" start trying to apply Taylorism (the only thing they know) to software development on top of JIRA. That's when you get JIRA tickets with vague descriptions like "simplify login flow" or "reduce memory usage" and some self-important jerk insisting that you either assign a "point value" to it and finish it in two weeks or "break it down into smaller chunks that you can estimate".
I've been at a few places where it was hideously slow and flakey (erroring just after you save a long story edit).
In recent years I've mostly used it in SaaS form, or at least very well provisioned.
I don't love it, and the UI is clunky (especially the messed-up almost-but-not-quite-markdown or wysi-almost-wyg) but it's usable, widely known, and as you note has some useful integrations.
Edit: the hard part - and this has nothing to do with JIRA is getting people to write well-formed stories. I have spent a lot of my professional life fighting to deprecate contentless stories!
Like I said, there are far worse things that could be forced on a developer team -- like VersionOne, switching away from which to JIRA will seem as a breath of fresh air.
"What are our team processes?"
"Oh, we use Jira."
...
I suppose that's not Jira's fault, exactly, but you can see why it would have a bad rap.
Just try to find a diff in a JIRA "issue". It's crazy how many clicks that takes.
Used it for 5 years at a midsized business and had an overall positive experience with it.
It quickly becomes not fine when you have PMs, Teams Leads and whatever creator vast amounts of workflow crap, automation, a billion tags, sprints.