The issue is the complexity of figuring out appropriate JSON-compatible serializations and getting the implementation correct for every single column in use. A simple example would be round-tripping the Postgres money type using salary::numeric and later (user_data->>'salary')::money
A much more complex example would be representing a numrange where you have to preserve two bounds and their respective inclusivity/exclusivity, in JSON.
i'm not sure I follow - why would they avoid using non-JSON types?
more generally however: I don't have a lot of insight into the usage/feedback for this extension, but I can ask the team