Private code could be marked with a special comment and tools can then prevent accidental release of private code.
I think it should take much less time to review code than to rewrite it from scratch, obviously, especially for very non-trivial parts like how to maximize utilization of the r600+ VLIW ALUs.Then there's the legal review. If you follow the news, you'll know how much work legal review is for the OS drivers that are mostly written from a known amount of documentation. Try to imagine sifting through a few hundred thousand lines of fglrx code to determine if it contains any licensed code that mustn't be shared, uses any patents that aren't covered outside of fglrx or tells internals about the hardware which AMD wants to keep secret.
When AMD/ATI's linux strategy was formed, opening up parts of fglrx was discussed. But it was deemed easier to start from the scratch.
The result may not be as fast as fglrx, but it's cleaner, better structured code. To me, that's more important.
Not to mention that the result is guaranteed to work well and be as good as the original one (if only non-essential parts are withheld), while starting from scratch gives no guarantee of matching fglrx performance at all.
But the really important thing is that the open source Linux driver would be at least partially a subset of the "real" driver that AMD really cares about, and thus would be guaranteed to be top notch and support new hardware immediately.
As long as the open driver is separate from the primary driver, hardware will always be supported months late (e.g. no HD 5xxx 3D support almost a year after release!), and the driver won't be competitive for 3D gaming, which is definitely not a desirable outcome for users, and arguably not desirable for AMD either (unless other concerns are more important).
Obviously, the ATI situation is still much better than the nVidia one, but it still falls way short of the ideal outcome (a top-notch open driver with full AMD software engineering support).