There were good reasons to change this to a real boolean. I think it was a WWDC, where kind of discussing this topic, one Apple engineer said they did an audit of production Obj-C code and found multiple instances where their BOOL values were values other than 0 or 1 (which was considered surprising and ultimately bugs).
This can lead to all sorts of subtle problems. One common one encountered by framework users is where something returns a BOOL and the user explicitly compared against == YES or == NO. If the value is say 2, then this code usually results in wrong decision.
As the implementer of an Objective-C dialect, I am considering to go the other route and elevate BOOL to NSInteger (sizeof( NSInteger) == sizeof( id) in my case).
Conceivably the compiler could (just) for @properties combine all the BOOL fields into a bitfield, so there would be less grousing about wasted space. Maybe or maybe not.
* https://developer.apple.com/documentation/objectivec/bool?la...
* https://github.com/iterate-ch/rococoa/blob/master/ObjcMsgSen...
It was well-understood that Obj-C BOOL and C++ bool are different types. Anybody working in Obj-C++ will deal with a ton of these differences, some minor (like BOOL) and some major (e.g. how NSString and std::string are not at all the same thing). Unifying a few bits here and there doesn’t deliver a lot of practical benefit.