The kdbuswreck

Simply put, the idea with capabilities was that a process that has root privileges shouldn't be able to do all that root can, but instead just a narrow slice thereof. This restricts setuid binaries to privileges required for their stated purpose, and nothing else. The desired upshot is a limitation of the damage from successful compromise of setuid binaries and (restrictable) processes otherwise running as root.

It likely didn't help that academia at the time was still mildly abuzz with capability-based this and capability-based that, and that the relevant research papers would read like exercises in ontological wank -- for example, calling a process' knowledge of a path name a "capability" as it makes the process capable of accessing that entry (or discovering that it cannot). While that way of looking at things does account for things like forking (which implicitly copies data such as pathnames), it has precious little to do with the split-root capability mechanism of Linux besides having a word in common and an application in the field of access control.

Historically, then, a "capability" can mean basically everything, which makes it a good word for marketing towards the uncritical and unwary much like "the cloud". [Imagine a snarky remark wrt implied corporate braindamage in systemd here.]