The isolated shell would certainly be cheaper for end users, and DSL designers can be hosted there. Apart from reanchoring artifact generation (which uses the IVsSingleFileGenerator-related services from the C#/VB project system), the problem is a licensing issue, not a technical issue.
Very earlier iterations of the NORMA tool tried to use more of the DSL-provided services such as the DSL-native Model Browser. However, the scaling on the DSL-provided browser at the time was pathetic (half second slow downs on any operation when the model was ~200 primary elements), so I jumped in to build my own system. The replacement choice of platform was the VirtualTreeGrid control that installs with Visual Studio. Although this control was not publicly documented, when I left Microsoft in 2004 there were plans in place to do that, and it was already in heavy use internally (the Class View used it, as well as several clients (profiler, etc) in the Team Foundation pieces). I was also quite familiar with the control (it was my brainchild, and I wrote the vast majority of the code). So, I felt confident in using it. Also, a replacement was prohibitive (the control has about 10,000 lines of code in the 'ITree' data engine, and about twice that much in the UI portion, so it is not a small project).
The following history was not so favorable: the documentation was not completed, minimal additional changes were made for 2008 and (?)2010, and (most relevant here) the control did not ship with the VS shell editions (MS would not pre-release a file list of what was shipping and what was not prior to the final shell release). We've tried various channels to get it either included or opened up as a community project, but to no avail.
The control is used because it is scaleable (performance is based on the number of branches, not the number of items, so population with n*10,000 items is instant), virtual (the control retrieves all data through the IBranch interface), and flexible (custom inline editors, expandable subtrees within a cell, multiple glyph sources). We use this control for the model browser (scalability required, along with glyphs and other inputs provided by multiple packages), reading editor (note the use of the inline richedit control, which you can't do in a normal tree), sample population editor (complex cell expansions supported for compound identified items and subtype instances), transaction viewer (one of the debug items, uses complex cells, inline expansions, etc), and most of the other list and tree-based dropdowns.
Of course, after several years of inactivity, the control is obviously long in the tooth, and occasional bugs have caused some problems. I'd also like more flexibility in display (variable item height, custom formatting within a line, etc), so I've been thinking about an engine rewrite and a rework of the control on WPF for a while. I think WPF will be a much better match for the virtual system than WinForms was, so I should be able to do the work with significantly less code. I just have to balance this work with other project requirements (including the model-integration area Jim also mentioned in this thread).
So, yes, I would love to have a standalone version in the VS shell host, but I can't legally ship it without writing a replacement for a component that is integral to the NORMA tool.