A 32 bit "fourCC" would be more than adequate. It could even be constrained just to readable characters, like LNXF (Linux Filesystem) and LNXS (Linux Swap).
If another OS happens to use LNXF for something, and you have that OS in the same darn system, it doesn't matter. You just don't have that "foreign" LNXF in your /etc/fstab, and likewise it doesn't have the Linux ones in its equivalent of /etc/fstab.
The only thing that needs a clash-free label is the EFI boot partition, so the boot firmware can unambiguously identify all these partitions on all attached devices and offer them as boot options.
If the argument you want to make is that they are of no consequence, then you need to answer why your proposal of still doing something is warranted.
Why not a nibble and just use the other 4 bits for flags?
The point of this line of questioning is you're quibling over bytes which definitely don't matter in any modern context, at the expense of masses of extra management complexity to try and avoid day-to-day problems when people want to stand up new systems.
With GPT, if I want to make a new filesystem type for some application, I just generate a GUID and it will not collide without me needing to coordinate with anyone.
16 bytes is an obvious example of the "second system effect" described by Fred Brooks in Mythical Man Month.
The fdisk utility now reduces the GUIDs to one byte codes that refer to the GUIDs. For instance, I remember that 29 is Linux RAID (previously FD). Will 29 always be Linux RAID everywhere? Probably not.
> With GPT, if I want to make a new filesystem type for some application ...
Four bytes could have an ample reserved range for local use by hobbyists.
Broad recognition of the code only matters if the application is very widely deployed.