To me they reveal a couple of misconceptions:
1. That a WYSIWYG should provide a pixel perfect like-for-like view of the front end on the back end.
As you mention, the theme you chose doesn't have full Gutenberg styling, so front and back end differences are more pronounced. But even themes that have good integration will display differences, because the back-end cannot perfectly model the front if users are going to do more than manipulate data inside it (i.e. change styling).
I do agree that there are other ways to provide more intuitive editing (like in-place editing), but they are not without downsides too. In-browser editing is a compromise and balancing act.
2. That the structural blocks around visual elements on the back end designed to enable UI elements and controls interfere with styling by theme developers in some way.
That was definitely my experience at first (I've just spent three months updating several themes for use with Gutenberg), but it isn't now that Gutenberg has evolved and I better understand how editor styling works. In short:
- You enqueue your editor styles after calling add_theme_support( 'editor-styles' ); with add_editor_style( 'style-editor.css' );
- You can then copy the bulk of your styles from the front end to that stylesheet (with a few exceptions, such as the post title, which do need editor-specific wraps at present).
- Gutenberg/WP 5.0 prepends those styles with a block-specific selector when you view the Gutenberg editor so that you don't need to worry about the “soup of UI markup”, as you put it.
- You can automate much of the CSS re-use using Sass, like the Twenty Nineteen theme is doing.
Theme developers need not think about the extra wraps unless they are developing custom blocks, and even then it's largely abstracted away for them by the JS API.
I would much rather have editor styling handled automatically by Gutenberg, and I think it will get there, but for the moment this is a small stepping stone on that path.