> I find it really weird that the openbsd pledge lets you just escalate out of it.

It's only weird because the normal M.O. with facilities in other environments is to sandbox specific, high-exposure applications, which are typically run in isolation, such as system daemons or end-user GUI applications. The semantics of pledge and unveil were fine-tuned from OpenBSD developers systematically sandboxing almost the entire base system--most command-line utilities in OpenBSD are pledged, as are all daemons.

Inheritance is only a "problem" if you're exec'ing other programs, but the vast majority of programs, even command-line utilities, never need to exec, at least not during runtime (as opposed to startup). Most programs using pledge drop the ability to exec entirely (i.e. don't specify the "exec" pledge), so inheritance is irrelevant as there could never be anything to inherit. (Note that upon the first call to pledge, you lose any capabilities you don't explicitly request.) But if you do need to exec other programs, then inheritance can quickly become a problem--counter-productive, even, as workarounds typically involve the parent program preserving permissions which it might not need directly. (Note that this is also why pledge and unveil are superior APIs to relying on the invoker--e.g. systemd--dropping permissions as only the program itself knows best which permissions it needs and when.)

OpenBSD is developed as a comprehensive system, and it's in this context that you need to understand pledge and unveil. On OpenBSD, if program A exec's program B, program B should be making use of pledge and unveil itself, and if it's not then that can and will be fixed. Unlike in the cat-herding Linux ecosystem, OpenBSD developers have little reason for a security model that prioritizes the ability for program A to implement workarounds for deficiencies in program B; their habit is fixing program B or refactoring A and B so they can work better together.