Four-char codes (aka OSType, aka UInt32) were/are fundamental building blocks in Apple event and other classic Mac OS APIs, where extreme compactness and machine efficiency were far more important than developer convenience or readability. (Mind, System 7 had to run on 8MHz 68030 boxes with a couple MB RAM.) Most of those old APIs have long since been taken out and shot, or at least heavily abstracted over by more modern ones (e.g. the UTI APIs don't just provide native UTI string support but also encapsulate all the old MIME-type and 4CC crap as well).
The only time the old crap leaks out is when using equally ancient crusty APIs like clipboard info which is horribly painful and obsolete nowadays. The fact that some of the type names returned by it appear as raw 4CCs in AS's 'chevron' syntax («class weba», «class RTF », etc. vs string, Unicode text) merely reflects the absence of a corresponding keyword for that code in AppleScript's own built-in dictionary (which is limited to the keyword-code mappings manually defined by the AS developers). And even if you do retrieve textual clipboard data in one of those alternative formats, it's usually useless to you anyway since AS can't do anything with data of that type anyway, unless you can find another equally ancient API that can also understand it.
The UTI system is capable and mature, and has been widely supported since 10.6 or so, so there's no reason not to use it when available, and plenty reason to avoid the ancient, gnarly, crippled schemes they've long since superseded. Doing otherwise is just making a rod for your own back: that such APIs still exist in AS merely reflects the AS team's failure to deprecate/modernize/replace them in pace with the rest of Apple; it's not a recommendation to use them.
..
As to the problems with JXA and symbolic AE types in general...
That JXA is incapable of representing 4CCs at all is due to its authors being dilettantes with no real-world experience in application automation and who repeatedly fail to dogfood their own technologies (Scripting Bridge, JXA, etc) or take expert advice from those of us who do.
In fact, JXA can't represent type and enum names - Unicode text, document, yes/no/ask etc. (i.e. values of type type class and constant) - at all. since JS doesn't have a native Symbol type, its authors thought they'd be clever and just use String, and have the bridge decide whether to pack those strings as typeType/typeEnum instead of typeUnicodeText descriptors before sending them in an Apple event based on what type of values the command's dictionary definition says is required.
This works in trivial cases, e.g. close saving [yes|no|ask], where the dictionary definition contains all the information required to determine the actual type required, but unsurprisingly falls apart as soon as you start to deal with more complex use cases where the required type cannot be inferred from the dictionary, or where the dictionary is insufficiently complete or correct. Someone with a deep understanding of AE technology would already realize this: application dictionaries' AETE/SDEF formats were never intended to be complete, comprehensive, accurate Interface Description Languages; merely translation tables for mapping human-readable names (aka 'application keywords') to and/or from the corresponding low-level 4CCs, and everything else is just there as user documentation, with no guarantee of completeness or correctness; thus trying to use the latter to do anything else is about as reliable as you'd expect.
Funny enough, the 10.11 prelease notes for JXA indicate they've disabled this 'magical' conversion behavior by default (no doubt because it was biting users in lots of other exciting ways that its authors failed to anticipate). There's no indication in those notes that they've added a Symbol class to represent AE type and enum names correctly in JS, so it should be fun to see what else breaks next.
