I see the same behavior in groff 1.22.4 and in the latest git code.  (And for that matter, going all the way back to at least 1.19.2.)

ASCII characters represented in \[u....] form are handled inconsistently.  A simple demonstration of the difference:

$ echo '\[u0021]\[u0022]' | nroff | cat -s
troff: <standard input>:1: warning: can't find special character '\!'
"

\[u0022] is correctly converted to, and output as, a quotation mark.  But \[u0021], rather than being converted to a "!", is for some reason converted to the sequence "\!", which (unsurprisingly) is not a recognized character.

It's not clear to me what internal mechanism might cause this: if "\[u0021]" were parsed as a backslash followed by "[u0021]", the bracketed sequence wouldn't be specially interpreted at all.

Looking at all the pre-alphabet ASCII symbols:

$ printf "\\[u%04x] " $(seq 32 64) | nroff | cat -s

Five of them are handled as expected, 15 are converted to unrecognized \ characters, and 13 are not recognized at all. 

That last case I don't consider a bug, since (current) groff does not specify that any of them should be recognized.  (The 1.22.4 groff_char(7) page sort of gave the impression that some of them would be, but these sequences have been removed from the drastically rewritten 1.23 groff_char(7).)  Arguably, none of this is a bug, since no documentation explicitly states that, for example, "\[u0021]" will be recognized as "!".  But the way it is handled is surprising enough that I wanted to at least bring it to the development team's attention.