Soft error handling *was* used for catching cast errors in the very early versions of this patch (long before I got involved and the infrastructure you mention got added). It was taken out after Pavel said [1] that he didn't like producing NULL instead of throwing an error. Not sure if Pavel's around but it would be good to know why he didn't like it at the time.
I'm personally in the "make it error" camp but "make it conform to the standard" is a stronger membership (in general).
I see this note in your linked thread:
> By the standard, it is implementation-defined whether JSON parsing errors > should be caught by ON ERROR clause.
Absent someone contradicting that claim I retract my position here and am fine with failing if these "functions" are supplied with something that cannot be cast to json. I'd document them like functions that accept json with the implications that any casting to json happens before the function is called and thus its arguments do not apply to that step.
Given that we have "expression IS JSON" the ability to hack together a case expression to get non-erroring behavior exists.
