This sounds like a rather specific feature, and probably challenging from optimization perspective (since no content within String values is dropped, although there is escape handling).

But wouldn't this be something that could be quite easily handled at level of UTF-8 (etc) backed InputStream? I assume it'd be fine to drop them also as part of insignificant whitespace?

For InputStream, Reader, one can register InputDecorator which is called by JsonFactory before constructing parser -- it could wrap input source in such filter.

I also thought about a custom jackson string type deserializer. But as you pointed out, that might come with a performance penalty :(. On the other hand, dropping such chars in general from incoming requests might not be always a good idea (binaries etc.). So a request input stream wrapping filter would have to be restricted to certain content types only.
Hm. Besides wrapping the input stream (which might also be a problem due to now non-matching content-length in stream and header) and not looking at performance, a jackson string type deserializer could be a way to go?