I agree, it's a good trade-off. In fact, that's exactly how I implemented it in the version that's inside Teensyduino.
The slow compiled code often requires almost that many instructions just to marshal the inputs into the required registers, when either isn't a compile time const. If the surrounding code is complex, but doesn't call other functions, which can often be the case with digitalWrite, the saving in register allocation are also a big win.
But that's not "exactly" how I wrote it. This "bitWrite" macro coding style really isn't my first choice. Inside Teensyduino, I implemented this using a giant chain of if-else checks, where each performs the desired write. While it's a lot longer, a LOT longer, it has the advantage of doing nothing if an illegal pin number is used. With this macro version, if an illegal pin number is used, it will write to the last pin. On all Arduino boards, that's an analog input, likely never configured as an output, so the effect would be activating the pullup resistor on that analog in... which could be pretty confusing if the poor, misguided user didn't realize some other unrelated code mistakenly wrote an illegal pin number. For that reason, I've never been very happy with this style.
Back in November 2009, David said he intended to include this into the official Arduino core, and he preferred this macro style (I had posted a short example of the if-else way), so I wrote it this way for contribution to the official Arduino version. Sadly, with 0018 gone by, and issue #140 not tagged for 0019 or 1.0, it seems unlikely these optimizations will ever become part of the official digitalWrite. Had I known that then, I wouldn't have bothered to write these for the official Arduino boards. I'm certainly not going to put any more effort into it now, other than pointing out this lack of checking for illegal pin number input.
Then again, erroneously writing to the last pin is a lot better than what the slow compiled digitalWrite does. It will happily use the too-large pin number as an index to an array, reading whatever happens to be in memory after those tables, and use that data as a pointer and bitmask to write to someplace in memory! Not good.
Then again, there's issue 146 & 170, which also seems unlikely to ever get fixed.
It makes me sad to see so little care and concern for code quality. I think maybe it's time to turn off my notifications for this thread....