What I meant by implementation is that you can implement your company's processes via JIRA configurations, workflows, and occasionally plugins in such a way that the way your instance operates is almost unrecognizable from the way someone else's might.

You can configure a nearly infinite number of input screens with all manner of standard and custom fields to be presented to users at any given point. The rules can be quite complex and handle forward and backward transitions. As a system administrator it can totally be overwhelming, but you are quite free to do most things.

If you have a process that default JIRA configurations doesn't serve well and drives users into deep menus and weird contexts, you can very likely fix it, or at the very least make it more palatable with those customizations.

For example, for a given project type, we don't just have To Do, In Progress, and Done. We have To Do, In Progress, In Review, and Done. When a dev moves from In Progress to In Review they are prompted to input a number of required fields so that QA can know how to test it, where to look for it, etc. If QA fails the review, they're prompted with a specific screen that brings forward the inputs they'd need to document why it failed. When they fail it, it automatically goes back to the dev that kicked it to review. When that dev kicks it back in to QA it's going to go back to the person that reviewed it the first time. This process, if done with no extra JIRA configuration would be a damn nightmare and it would break down fast. We spent the time to make it fast for everybody using it, and to make sure that they are presented with the things they'll need when they need them.

If JIRA is new to a team I recommend they run it completely vanilla for a while and then come up with a list of things they'd need it to do or do differently to fit their meatspace processes and interactions. I'd also look at what you could do to make your existing processes more streamlined that might cut some of the complexity in the first place. Vanilla JIRA Agile is actually fairly simple and only more complicated than Trello because of the UI and various issue types. You'd be surprised how far it can take a team if you don't have some arcane internal requirements or unrealistic expectations of the software revolutionizing your team's performance. At my last company we quelled a near JIRA revolt (it was there before me) by literally just going to default JIRA Agile workflows.

I do agree about the 'markdown' support in JIRA/Confluence. It would almost be better if they just didn't support anything than the way they support it. I've got a lot of gripes with JIRA around UI/UX issues, but the vast majority of hate I hear spewed at JIRA is usually because they had really crappy (or just complex) team processes implemented with crappy JIRA configurations and it made everyone's life hell.

I'm not a JIRA apologist or anything, if there was something else out there that was better and had the same level of available integrations (Jenkins, Slack, support desks) I would cut over in a heartbeat. I just think it gets a worse rap than it deserves (not that it doesn't deserve some mind you). Confluence on the other hand, that deserves every complaint I've ever heard about it...