I'm not very well versed in it myself, but while possible, my understanding is that trying to merge two leaves will result in needing cascading changes up the tree. Plus there may be some other things that need editing that depend on the structure, or maybe even checksums somewhere that need recalculating.
I am however quite certain that significant optimization cannot be found there. Technically, the more leaves the world is split into the more optimized the map CAN be. Larger leaves obvious more will be rendered. Current "optimization" methods are actually striking a balance between compile-time and run-time optimization. We all know the effect on a compile it can have with lots of leaves, but that may technically result in an marginally faster rendering map - up to a point, there is likely a point where you have too many leaves and it will bog down run-time calculations.
Our methods also deal with "correcting" things that VBSP isn't written to consider or otherwise overlooks, which brings me to my response to henke. Hint will not always overrule VBSP. It will always make a slice, but there are some cases (especially when you are hinting flush with another face in an attempt to prevent a frivolous outward cut - like in our case here with a two part wall) where VBSP may still decide to cut something.
I have seen cases where you have two walls like so: |_ with the end of the bottom brush butting up against the inside of the left brush. VBSP then makes a cut on the OUTSIDE of the building, along the plane of the INSIDE of the bottom wall - even though that face doesn't even touch the leaf getting sliced.
When it comes to leaves, the only absolute in stopping cuts is the 1024 unit rule.