One of the big divisions between NFS v3 and NFS v4 is that NFS v4 is normally used with Kerberos. In normal configurations, this means that Kerberos is used to authenticate user requests; a NFS v4 client that claims to be making a NFS request on behalf of a given user must prove this by presenting an appropriate Kerberos ticket. This is different from NFS v3, where normally NFS clients are trusted by the NFS server to identify which UID the client is making the NFS request on behalf of. A while back I expressed an opinion about this on the Fediverse:

Hot take on NFS: NFS with Kerberos and NFS without Kerberos are two different things that aren't all that comparable, and Kerberos for NFS is a very limited fix for a very limited vulnerability that doesn't apply to most people.

(NFS with Kerberos could in theory be used for wide-area file sharing access, but in practice I believe this is almost never used. Especially over the Internet.)

In my view, the primary threat this form of Kerberos protects you from is untrusted single-user machines that claim the user has logged in to them when the user hasn't. If you trust the machines, you can trust their claims of what user they're acting on behalf of. If you don't trust a machine and people log into it, it's game over for every user that logs into the machine; the machine acquires access to their Kerberos information and can now make whatever NFS requests in their name that it wants to. If you can't trust a multi-user machine, you shouldn't allow people to log into it. So the primary threat you're protecting against is an untrusted machine operated by user A claiming that it's actually acting on behalf of user B, when user B has never touched the machine.

This is a common threat profile in the individual laptop and desktop space. But very few people are trying to use NFS in that environment (and for good reason); most commonly people use SMB/CIFS there. NFS today is mostly used between servers, where this threat is mostly not applicable.

Why this form of NFS with Kerberos isn't particularly comparable to NFS without it is that this form of NFS with Kerberos requires you to give up essentially all unattended operations that NFS clients might perform on behalf of users. Crontab entries, web CGIs or long running web server processes (including ones you want to use to get around file access permissions), server side filtering in your mail system, sufficiently long running compute jobs in your SLURM compute cluster, automatically distributed containerized workloads, generally none of those work because none of them are in a position to get the necessary Kerberos authentication from the actual person involved. All of them have to say 'trust me that I'm acting on behalf of this person', and in the usual form of NFS with Kerberos the NFS server's answer is 'no I don't trust you, prove it'.

NFS without Kerberos can be used on NFS clients as more or less just another Unix filesystem, although sharing a single area between NFS clients may require some additional work. The normal form of NFS with Kerberos can't be used that way because to a large extent it can't be used for what we could call 'background' activities, only for 'foreground' ones that happen when people are actively logged in. In many environments, ours included, these 'background' activities are quite important for the overall system, which means a switch from NFS without Kerberos to the common form of NFS with Kerberos would be a serious loss of capabilities.

(If you do face the threat that NFS with Kerberos is good at defeating, then you probably have no choice; you can't use NFS without Kerberos.)