I agree with the other answers, but want to add one thing.
who are constantly changing the requirements so there end up being of small cosmetic bugs that need to be changed
A change in requirements is not a bug. If a developer does the work according to the prior requirements and does it correctly, the changed requirement is new work. New work needs to be budgeted for and prioritized accordingly. You can't just stuff it into existing tickets without things being delayed or pressuring developers.
I can see the argument that tickets for small fixes would not be required, but that would only be true in startup type companies where the developers understand what the product is and only with minor tickets. If the developers must answer to someone else, they want the tickets to justify why something took so long or what work they did last sprint.
If the tickets are being tied to velocity or points, then stuffing the fixes into other things also hides the true cost of the project (or the cost of the indecisive project managers).