Can you ELI5 what the implications of this are?

Of just this specific change in the patchset I highlighted, or the whole thing including the previous open_tree patchset? Absolutely not, but I'll try to explain this small snippet to the best of my knowledge at time time.

in this small sample of code:
If your kernel disables userns then nothing seems too different. Basically, there is a new system call called fsmount (there are more now that I'm looking closer...) was aded into the kernel, and systemcalls can be called by any process so long as it's not blocked by a seccomp filter. I don't know much about it since I stopped regularly reading LKML due to the Coup of Corporations that resulted in the creation of corporate safe space doctrine to protect them from harsh criticism and create a chilling effect on truly free discussions.
It works on filesystem mounts which are privileged operations, meaning the process calling that function must hold the CAP_SYS_ADMIN capability to modify the filesystem topology. If your kernel has userns enabled then users can create new namespaces that have a different set of capabilities from the initial capability set, specifically to dodge this sane requirement as security is done in layers much like a house of cards. Don't ask me who thought it was a good idea but now with user namespaces there is some extra considerations to add to your cognitive load when checking permissions as you can see here in this patch.
Its changed one simple may_mount() call (which all the old mount checks use afaict) into two branches, the new branch checks for capability using ns_capable(current_user_ns()), where the old code using just may_mount() always checked ns_capable(current->nsproxy->mnt_ns->user_ns).
Seems whatever this new feature is requires checking only the current namespace's capabilities instead of going through current->nsproxy mount namespace for reason's I'm unmotivated to learn because it's a feature that seems to have no serious use case, much like open_tree. It's a better use of my time to create a patch to remove such dubious functionality at compile-time than attempting to justify why it should exist in my OS.