I think the point is that an admin shouldn't configure these executables to be run at a different privilege level, as they are not written with that kind of security consideration in mind at all.
I think it's more like "what you can use in your toolbox for effectively exploiting some privilege escalation vulnerability".
SUID is very explicit a tool only to be used for a very few niche use cases with very carefully crafted binaries. Basically a learned sysadmin putting SUID on an arbitrary binary (like most in that list) is enough reason to fire them for gross negligence without any prior warnings even in countries with strong employee protection, it's _that_ big of a "wtf. did you non accidentally do". So you don't really need a list for that.
Similar as any small tooling binary (e.g. cat, base64, etc.) is _supposed_ to run under sudo, i.e. it's definitively not a case of "not written with that kind of security considerations in mind".
Also for sysadmins this list isn't that useful as there are any number of arbitrary additionally binaries which behave similar on most systems, i.e. the list is very incomplete (and there is no way around that).
Similar "being able to read/write a file with the permission the calling user has" is normally not something you care about, the caller is anyway allowed to do so.
Or being able to trick a program to work as a form of shell (limited to the users permission) also normally doesn't matter. The user just can spawn it explicitly.
Except if you build a toolbox you want to use after finding some (potentially limited) exploit (or if you want to consider what such an toolbox would likely use). Then is list is grate as it makes it easy to find a way to archive something (e.g. shell) with as little custom code (and potentially without it being obviously in monitoring tools).
