Right, Reaper does not support VST3.
And it definitely cooks with water, means it absolutely can crash and do odd stuff.
As for plugin handling:
It tries its best to handle plugin crashes gracefully and you can be lucky getting a crash and the host survives (to my knowledge Sonar tries that as well), but many plugin crashes will still drag the host and maybe the audio driver with it, just like in any other DAW. If you don't take extra steps, of which there are some.
There are some extra compatibility modes the user can choose for misbehaving plugins which are working pretty well, using some security measures like zeroing out buffers before giving them to the plug, extra samples at loop edges and such. These modes helps a lot with sloppy coded plugins already (but wouldn't prevent Reaper to crash if a plugin crashes anyway in an ugly kind of way).
Another method to cope with crash prone plugins is very useful, and maybe something to consider implementing in Sonar (if there isn't something like that already): you can run problematic plugins in dedicated processes, so that they
can't drag the host down when they crash, but only its own process (they can still take the audio driver down, so you have to restart, but as the host is still alive, the situation loses much of the horror). Because running separate processes taxes the cpu a bit this is not done automatically or for every plugin. You have to set it yourself on a per-plugin basis if you have a plugin of which you know it will occasionally crash, but you like it so much that you want to use it anyway (btw, this mode was also cool in the 32bit world, as it allowed the plugin to access it's extra share of RAM).
Saying this not to tout Reaper here, just to prevent myth spreading. Reaper doesn't do magic, just stuff every host can consider to implement.