Because we can usefully assign distinct values in a context like "Windows plus Linux box" in which we don't care about some exotic file system that was once used on a DEC VAX or whatever.

So why not use a single byte? How many machines do you know which have more then 255 filesystems on the one disk?

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.

Indeed; one byte works for me. Four is a reasonable political compromise between "one byte works for me" and "oh my, what about clashes?"

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.