You're describing canonicalization, which incorporates elements of the encoding format into the final hash, and therefore does not facilitate retaining the same content hash when transcoding to different formats.
Also, canonicalization is a bit of a mess. There are several incompatible canonicalization schemes for JSON, and even within a single one of those people have a difficult time implementing them correctly. See e.g. https://github.com/theupdateframework/tuf/issues/362
You seem to have missed the point: it's not a canonicalization format. Content-aware hashing is a more powerful alternative to canonicalization which avoids many of the problems involved in designing a canonicalization scheme.
I'm not sure what you mean by "terseness". Do you mean the size of the spec? Because as serialization formats go, it is on the short side. However, typical JSON data is anything but terse; it is almost the most verbose serialization format in use, beaten out only by XML. Which I suppose could be where you're getting the idea that it is terse from, but in that case, it is "terse" only in the sense that it is the second worse of all the couple dozen common formats. It's kind of like how I've said a couple of times on HN that new compiled language designers should be grateful to C++ for setting the bar for compilation speed so low; it makes it very easy to put "compiles more quickly that C++!" into the initial elevator pitch. However, you are not "fast" merely by beating the slowest, nor are you "terse" merely by being slightly more efficient than the worst.
Also, canonicalization is a bit of a mess. There are several incompatible canonicalization schemes for JSON, and even within a single one of those people have a difficult time implementing them correctly. See e.g. https://github.com/theupdateframework/tuf/issues/362