This discussion is fantastic and I love all your points 
There are indeed separate parts of the problem here:
WYSIWYG Text editors
They would always be a vital part of the āfrontendā content editing process and I think we all agree that thereās not a single usable editor out there so far. There are many interesting approaches coming up at the moment though. A friend of mine is working on https://beta.frontkit.io/ which looks extremely promising. Prosemirror is another one that separates WYSIWYG editing from the generated code: http://prosemirror.net/ But in my opinion it will still take a bit until one of them will be completely ready and easy to integerate.
Frontend editing
As you already pointed out itās extremely difficult to combine a good frontend editor with any possible theme. You would always need to introduce some restrictions in order to make it work or the number of possible problems and bugs would be endless. I agree that the coding effort should not necessarily determine if something should or should not be done, but itās more a question of stability and maintainability here. Nobody wins if the solution is buggy as hell or breaks with every new theme.
Thereās another issue here. Iām a big believer in a clear separation of data and display. I come from a background of building websites for more than 14 years. For years, before the rise of the mobile web, the data for a site and the display were very tightly coupled. You would build for one medium: a desktop browser. The only variable was a very limited number of screen sizes and resolutions. But in my opinion with the rising focus on content and the multiple devices and screen sizes we have to build for today, we should put all our effort into a very clear separation of content and design as far as that is possible. As a designer I definitely donāt mean that the design should be done without considering the content, but that the content should be flexible enough to fit into multiple designs. Karen McGrane has given a fantastic talk about this at beyond tellerrand last year on how we need to structure our content in order to make it available for any upcoming medium or device. The best case szenario in my opinion is that the CMS becomes a single source for content for a company and that content can be used for a website, a mobile app, a watch app, a bus stop ad display, imported into indesign for a brochure, etc. etc. That means that there has to be a very well designed underlying structure for each type of content. Thatās exactly what I try with blueprints. The more well defined fields, the better. Karen describes WYSIWYG output as very similar to a PDF. She calls it a blob. A huge container where you just dump crap into and you can never get it out again in a usable way. That has to be avoided at all cost.
But I also agree that there are often use cases where users need to partly design longer text and combine it with quotes, videos, images, etc. and plugins like @timoettingās blocks field are the way to go here if you ask me. The process of creating content is very playful for users and the result is still super structured.
I think in the end itās all about providing better fields in combination with a better preview mode. If you ever used the new Swift Playground tool in XCode, thatās exactly what I have in mind. You have your form on the left and you can make changes there, which instantly get displayed in a live preview on the right. That way the live preview can be anything and it doesnāt matter how the code for the frontend looks. I already have some plans for it and I hope I can start working on it soon.
So those were my quite long 50cent