You understand the problem correctly.
It's not a bug, it is a missing feature; ie., this has never been hidden, it has always been working per specifications and/or documentation.
The preferences input function uses Capability solely as a Device selection filter, not as a way to define and restrict granular access to specific functions (Attributes, Commands, Events) from the Device. This may have been on the wishlist, but was never implemented. Thus, not a bug — I don't even think it should be called an "exploit", because it is not a hidden vulnerability; (except for the lack of Customer education?).
Similarly, the Location Object is fully open to any installed SmartApp, because no preferences/input statement is required for the app to use it. I raised this concern multiple times including a simple practical fix (make "Location" or its functions a type of Device / Capability).
location.mode (and SHM mode) is sensitive functionality since it is often used to arm/disarm alarms, right? So giving a Battery Monitor SmartApp the right to use it should require explicit user permission, otherwise only a code review can prove that any SmartApp is not changing your Mode and disarming your home!
The issue with Device function granularity can be mitigated with the use of Virtual Device Types and instances... For example, you could create twp separate devices of type Unlock and Lock with distinct properties. If the platform had a simple inheritance paradigm, this structure might even be practical.
Maybe this can be done with abstraction under the covers, but it gets super complicated because ad hoc Attributes, Commands, and Events (ie, those not in an official Capability) will also need to be presented in an understandable granular fashion to users. Gets confusing for the average consumer really quickly.