The circumstances under which a clickjacking attack could be introduced to an otherwise secure site are quite narrow:

  1. Attacked site use Javascript anti-framing protection 
     (otherwise there is no benefit to the attacker in 
     disabling Javascript).

  2. Attacked site doesn't use X-Frame-Options to prevent 
     framing (probably rare for the bigger sites these 
     days).

  3. Attacked site allows the functionality under attack to 
     work even when Javascript is turned off. Many common 
     clickjack targets (e.g. Facebook Like buttons) don't 
     work at all with Javascript disabled.

  4. Attacked form has effective CSRF protection tokens 
     placed in it server-side (otherwise it would be easier 
     to do a CSRF attack rather than CJ and get the same 
     result).

I think that the circumstances under which the attack would be possible might be quite rare compared to those in which the sandbox feature would be a benefit.

One protocol fix that might get the best of both worlds would be to add a new X-Frame-Options token that indicates that the sender of content 'consents' to it being framed in a no-script sandbox provided it is consistent with the other X-Frame-Options. If the embedding frame requests a sandbox, and the embedded content doesn't have the appropriate X-Frame-Options header allowing no-script embedding, the frame just displays a browser error.