If you disallow TODO comments, you will lose that context, or at least it won't be easily searchable anymore. Issue trackers are not a solution because:
- they create too much friction. A developer that is short on time might add two or three comments to suboptimal code rather quickly but would likely not bother dealing with a clunky UI like JIRA, having to write detailed descriptions referencing the exact place of the code, filling out 20 fields and then being hounded by a PM who (rightfully) doesn't understand what "implement foobar() in linear time" or "make Frobulator thread-safe" means.
- Comments are right next to the code, issues are not. I see people pointing out that comments can get out of date, but so can issues in an issue tracker.
- IMO, "refactoring tickets" tend to be the worst tickets, they're rarely fun to work on, they don't include the context for why the refactoring might be necessary or what the best way to evolve the code is, and if someone else is assigned to the issue than the author of the ticket, they might not even understand the intended refactoring. A comment is much more light-weight and optional and anyone who touches the code can read it and decide whether it makes sense to fix it. It's also almost impossible for a PM to know how to prioritise refactoring tickets. IMHO, unless we're really talking about refactoring entire systems, refactoring should preferably be done continuously whenever the need arises, i.e. "first make the change easy, then make the easy change".
- of course, code shouldn't be merged if there are glaring issues that don't implement the feature correctly / could break important things. It's the responsibility of the developer and the reviewer to make sure that this doesn't happen, regardless of whether there are "TODO"s or not.