I have used bitbridged plugins with complete success. In fact one very nice DX plugin which is only 32 bits Sound Stage needed to be wrapped in a DX to VST wrapper for it even to be seen by bitbridge and it ran without issue in Sonar X2 64 bit.  I haven't used it in X3. I do have a couple 32 bit VSTis I use in X3 64 bit and no issues. I would also make sure that your memory is in perfect shape and that they are 100 % matched.  Same modules from the same batch and that you have enough. You should have a crash log to look at that will say where the crash starts. 
 
 

What are the plugins causing issues?

I don't know for sure specifically if this was the plugin, but it was one of Poulin's amp sims. After the crash I rebooted and used a 64bit amp sim, no crash.
 

FWIW I've been told that majority of Cakewalk's tech support calls involve third-party plug-ins.

Anderton
FWIW I've been told that majority of Cakewalk's tech support calls involve third-party plug-ins.

Somehow that just sounds right. 

I am not sure if I caught all of the context of this thread, so not sure if the crash is more on exit or save. A hang on exit can easily be caused by taking resources away from SONAR that it is using. SONAR does adapt to this but can take a moment to do so (Windows is the "middle-man" for this, and SONAR is dependent on Win7 to tell it what is available). When exiting always save/exit SONAR before removing a MIDI controller or audio interface (reverse is true for bringing SONAR online).
 
The reloading the E patch being a temporary fix sounds odd; there has to be a very repeatable recipe causing this issue (plugins, drivers, work flow, and the like). Win7 can also be invasive in taking control of an audio interface unless forced not to (making it unavailable to SONAR). I am not familiar with your interface, so not sure if it plays well in the sandbox with others "sharing" it.

Do we blame the plug-in makers for not following the correct guidelines of the API, are the guidelines for the API not thorough, or could the API need more attention, itself? I'd be curious what the root of the issue in % support calls being 3rd-party plug-in related.

Well many plugins work and others don't so I would draw some obvious conclusions from this. On the other hand bitbridge might not work well with certain plugins (either blame the chicken or the egg). It would also be very easy to taint all scenarios under the same brush.

Also note it's unlikely cakewalk gets full access to the third party code (it's not their job to debug other people's code either).

Another thing you might consider is JBridge. I don't use it (I try to use 64-bit plugins only), but I've read here (and in other forums) that for some plugins jbridge works better.
Try the demo with the 32-bit plugins you have to see if it works for you... (http://jstuff.wordpress.com/jbridge/)

If the OP has a dense project (lots of tracks/EFX):
I'd first make a copy of that project... for test purposes.
 
Now, load that copied project in Safe Mode (to strip out all plugins).
Try running this project (sans EFX/processing) for a good while.
Loop it, start/stop transport many times...
If this project runs completely stable for extended periods (over multiple sessions), you now the issue is plugins.
If the machine still crashes, it's time to test the system's RAM.
A bad stick of RAM can cause major stability issues...