JSON just doesn't fit that profile. Neat implementation, but don't give the impression that any of this would help with embedded.
Sometimes you don't get to choose what the source format is because you're consuming someone else's data feed, and if all they offer is JSON, you parse JSON. Also, on a 400-ish mhz ARM with 64 MB of RAM parsing reasonably sized JSON data is no big deal in native code.
You need to further qualify your comments beyond just "embedded" because what you're now talking about (very low mhz, KB of RAM) is a niche within the larger embedded world.
Sure, it sounds like a bad idea, but it wouldn't be the first time someone has had to do something crazy for compatibility with someone else's stuff.
For me, that means code space and RAM measured in kilobytes, cycles in MHz. Most people don't realize that serializing data (most importantly, floating point numbers) to strings is a complicated and time-intensive matter. Even a limited printf implementation can easily cost you many kilobytes. Not to mention it introduces you to C's most special hell: variable length memory blocks containing strings.
The one thing that embedded gives you is a lot of control about your computing environment. Just sending around binary data is a very viable thing to do under these conditions. Not so for JSON; its single biggest selling point is that you can use it in every platform out there. Its the oldest tradeoff: giving up flexibility allows you to use more constrained processors (and save money).