That seems like a rather pointless thing to do at this point. There is a lot of code out there using these templates, they won't be removed in the foreseeable future anyway.
Even removing trigraphs and the conversion from string literal to non-constant char* took quite a while, and at least the former was not even undisputed. (IBM wanted to keep them iirc.) Those templates have and had valid uses in current modern C++; they are here to stay†.
Note that deprecating a feature in the C++ standard is a fairly drastic step, placing it under review for future removal. It is meant to be a temporary state; either the feature gets removed at some point, or is restored to be non-deprecated:
With the release of a new C++ standard, we get an opportunity to revisit the features identified for deprecation, and consider if we are prepared to clear any out yet, either by removing completely from the standard, or by reversing the deprecation decision and restoring the feature to full service.
In an ideal world, the start of every release cycle would cleanse the list of deprecated features entirely, allowing the language and library to evolve cleanly without holding too much deadweight. In practice, C++ has some long-term deprecated facilities that are difficult to remove, and equally difficult to rehabilitate. Also, with the three year release cadence for the C++ standard, we will often be considering removal of features whose deprecated status has barely reached print.
From P0619R3, emphasize mine.
†At least for now. I'm not a member of the committee, so I can only speculate, but I would not rule out the possibility of deprecation at some point in the future, after concepts have settled in and if it becomes evident that the old helper templates do more harm than good.