The other two optimizations I could see either having no impact on code maintenance, or maybe even improving it. The bitfields thing though I'd have to see super compelling benchmarks to be sold on.
Now imagine the same object with a bitfield. That's one property (it'll happily hold 32 bits without hacks). So, with a header, that's 24 bytes.
That's a 4x savings. This will add up quick if you allocate the object frequently.
But maybe you're talking about speed. After warm-up, accessors and consts carry no cost. Before warm-up, it's probably still a net win to have bitfields.
After warm-up, in WebKit at least, accessors will get inlined and the compiler will be smart enough to constant-fold references to global variables (or almost any other kind of variables) that were effectively constant.
As for before warm-up, it depends on how frequently the object in question is allocated. Accessing through an accessor before warm-up carries some cost, but on the other hand, allocating 4x fewer bytes could be more important. It depends on the application. If your app uses too much memory to run reliably on some devices, then you'll probably be fine with losing some perf before warm-up in exchange for being able to not run out of memory. Also, GC is expensive and it is triggered by the combination of how much you allocate (in bytes) and how much is live at any time (in bytes). So reducing the sizes of objects reduces the amount of GCing you do, which causes your program to run faster. Probably in lots of large apps, the speed-up from GCing less will be greater than the slow-down from accessor calls during warm-up.