A few months ago I was part of a meeting where we had a big and long dicussion about @todo annotations. (and also the similar ones like @fix, @fixme and so on) The argument was, that they will not be solved, are there for years and nobody cares. Therefore they could also just get deleted. And if there really is something which needs to be done, there is a Ticketsystem for this.

In a perfect company/world I would say yes, thats a complete valid Point.

But the reality often looks different.

My first point is, writing a @todo is very fast and easy. You still can put more work into it and write a bit more comments to it, but this is mostly kind of formless. But writing a Ticket requires some form. You need to write a clear description of the problem, the wished outcome, the estimated amount of work and also decide which team is responsible for this.
Sometimes just fixing it is faster then writing this tickets, but in big companys you likely get admonished for just fixing something instead of writing a ticket.

My second point. Usually this tickets get priorized very low, which often leads them to rot for years. While I have personally no problem with this, it will cause some problems. For example switching to a new Ticket System often enough does not involve migrating all the tickets. Then there are sometimes cleanups, where old and low priority tickets get closed, or sometimes even deleted.
But the most important part for me is, if someone else works on the same place later, she will not see there is a todo. Maybe it would be even part of the task to actually touch the specific place and doing it would be easy as part of it. Also there may be a little chance this part gets just deleted, which then would lead to the ticket be there, but the code gone.
And also a great case, the code got moved. So the ticket points to a non existing file, but the problem is still there.

My third point. It is the only place where we as Developers have control over the communication. Communicating found Issues over Tickets or even Managers makes both sides, the sender, and the receiver, vulnerable. Doing it the official way is very likely leading the management to think, there may be potential to optimize the Developer performance by better micromanagement and preventing them from doing "unnecessary fixes".
They will not like the created tickets, as scheduling and resolving them costs time. Time they want to use to hit their own Team goals.

Also keep in mind, you are always just one day away to being completely out of the project and the company. At least try to leave a good legacy, so the poor souls after you can survive a bit longer in the company.