"Just run it as root" is how it usually starts. In Kubernetes, a container running as UID 0 shares the host's user namespace by default. A container escape hands an attacker root on the node. Runtime vulnerability, kernel bug, misconfigured volume mount: any of them will do it. Running non-root does not prevent escapes, but it limits what the attacker gets. UID 1000 with no capabilities is a much smaller blast radius than root.
The friction usually shows up with volume ownership. Mount a PersistentVolume into a pod and the files are owned by whoever wrote them last. Upgrade an app from UID 0 to UID 1000 and the new process cannot write to files the old one created. You get a read-only database error at runtime that looks completely unrelated to the upgrade. Reverting to root is the obvious fix and the wrong one. fsGroup in the pod's securityContext is the right one: Kubernetes chowns the mounted volume to that GID before the container starts.
Security context is not boilerplate you add after an audit. It is a decision about blast radius. You are deciding at design time what a compromised pod can reach, not discovering it during an incident.