JSON is a text format. A parser must recognize the text `2` as a valid production of the JSON number grammar.
Converting that text to _any_ kind of numerical value is outside the scope of the specification.
(At least the JSON.org specification, the RFC tries to say more.)
As a textural format, when you use it for data interchange between different platforms, you should ensure that the endpoints agree on the _interpretation_, otherwise they won't see the same data.
Again outside of the scope of the JSON specification.
The more a format restricts, the more useful it is. E.g. if a format allows pretty much anything and it's up to parsers to accept or reject it, we may as well say "any text file" (or even "any data file") -- it would allow for anything.
Similarly to a "schema-less" DBMS -- you will still have a schema, it will just be in your application code, not enforced by the DBMS.
JSON is a nice balance between convenience and restrictions, but it's still a compromise.
A JSON parser has to check if a numeric value is actually numeric - the JSON {"a" : 123456789} is valid, but {"a" : 12345678f} is not. Per the RFC, a standards-compliant JSON parser can also refuse {"a": 123456789} if it considers the number is too large.
I once debugged a production issue that boiled down to "A PCI compliance .dll was messing with floating point flags, causing the number 4 to unserialize as 12"
