Your developers should not be correcting punctuation
A support lead reads an error message and sees the problem immediately: the sentence says "invalid" where it should say which field is wrong. She writes it down. It becomes a ticket. A developer picks it up two weeks later, reads the ticket, opens the file, changes six words, opens a pull request, waits for a review, and ships it on Thursday.
Nothing there went wrong. Everyone did their job. And an engineer spent an afternoon on punctuation.
The three costs of that afternoon
The obvious one. An hour of engineering time, including the context switch in and out, for a change that took ninety seconds to make.
The one nobody counts. Every small text fix goes through the same queue as real work, so it competes with real work. Most of them lose. That is why your product is full of sentences everybody agrees are wrong.
The one that hurts later. The person who knew what the sentence should say never touched it. The developer implemented a description of the change instead of the change, and the result is usually close but not what was meant, which produces a second ticket.
Why it keeps happening
Not because of priorities. Because of permissions.
The sentence lives in a file in a repository. Editing a file in a repository requires commit access, review and a release. So the work goes to whoever has those, regardless of who has the knowledge. Your process is routing on access, not on expertise, and it is doing that correctly.
Which is also why "we should give writing more attention" never changes anything. The next sprint arrives and the routing is the same.
What developers should own
There is a clean line here, and it is not "developers should not care about words".
Engineering owns when something appears: which condition produces which message, what happens after, how failures are handled. That is logic, it belongs in code, and it should go through review.
Whoever explains the product to users owns what it says. Support hears the confusion first. Product knows what the feature is for. Neither of them needs a branch to fix a word.
Once the sentence has its own address and its own publishing step, that division works without anyone agreeing to a policy. The text is simply somewhere else, and the people who need it can reach it.
What your developers get back
An afternoon here and there, which is worth something but is not the point.
The real return is that they stop being the bottleneck for a category of work they cannot do well anyway. They do not know which sentence produced this week's tickets. They should not have to.
How to check whether this applies to you
Look at your last twenty merged pull requests. Count the ones whose entire change is text.
If that number is zero, either your interface text is already somewhere else, or nobody is fixing it. Both are worth knowing.