The ticket needs to be filed in the right queue. It needs the "right" tags. It needs to traverse the "approved" workflow correctly. It didn't get assigned to the right epic. etc, etc, etc.
It's all of that - the process built up over time, in response to organic needs - that makes things "slow" and drives such a rejection of these tools by developers and their teams. We (collectively) rarely step back and say "what process can we cut?" - only when we use a new tool do we have the chance to address that.
Then, on top of it the flows in Jira can be super slow, which is another story.
People complain about Jira being slow (me being one of them.) No one has claimed that all issue trackers are slow. ClickUp, Hive, Linear, are all snappy.
I don't think he literally meant that the app's performance was slowed down by the volume of tickets. I don't think Jira's performance gets much worse even with 10,000s of tickets in it.
The baseline performance of the web app is just baseline bad though.
"New issue trackers feel faster for the same reason switching browsers tends to feel faster—you're getting rid of all of the crap you piled up in the old one. Don't migrate your backlog, start with only a couple engineers in a new issue tracker, and suddenly, wow!, this new tool is so much better!"
I guess it can be read either way.