OpenBSD doesn't do different user accounts inside vs outside sandboxes; if you're root in the sandbox, you're root on the system.

unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.

The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.

So what? You're still root. You're relying on a sandbox to plug a few voids while you still effectively held keys to the kingdom before said voids were plugged.

I hear this excuse daily from developers who insist on running all their docker containers as root "because we have to".

If you're relying on a sandbox as your first line of defense you've already lost the war.

You left a snarky comment, then paraded around a positively lame example as some sort of trophy.

Here's what I can figure out: you need root to set up the environment just so. It's a don't-care. The end.