It’s a trade off for sure. But if you know at the time of collection all the ways in which your data is going to be used in the future, you work at a more well-run organization than me!
What do you escape for? Html? Postscript? Json? SQL? Latex? Custom report generator which haven't been created yet but you'll start using in 2 years? Things move - you can't choose the escaping format at input time.
For SQL you already have the language provided sanitation of prepared statements. For most backends, the output format is always json, which ends up on the frontend via dedicated browser APIs that don't allow html injection.
Maybe if you also directly render some html from the backend, that would change things.
Document these assumptions in your central code standards/architecture document to get everyone aligned, and then just stick to it and enjoy a more sane codebase.
So what you're proposing is encode to html on input, to sql on output, passthrough to html, and encode to Json on output but after decoding from the saved html - and just document it well?
I'm not sure, I've never run into this issue. I'd probably just look for another job if you want the honest answer.
For what it's worth: if a column in your database is used in so many contexts, you could document that it's simply unsanitized. Like, I prefer having as few entries for bugs and fuckups, and knowing that the database data is always sanitized helps with that. But it's not an unbreakable, absolute sort of rule.
And I never really escape strings for SQL, as I always use prepared statements - forgetting prepared statements is an easy thing for code review to catch.
I also have a project where there is HTML stored, which is not escaped because the purpose is to directly output that HTML somewhere, and it really is supposed to be HTML.
It simply depends. But as long as it's documented, and hopefully as clear and consistent as possible.