Hi Mark,
All your concerns are legitimate. However read below for some technical details and workflow ideas. I’d like to paint a brighter picture of the tool 
That’s not entirely true. For starter, what you build in Webflow IS the code. There is no abstraction. A box you create is either a div or another box html5 element.
Apart from some pre configured components like Columns or Slider, what you put is what you get. On top of that, you can analyze the content of such components in the Navigator view, and select and alter their inner elements. They’re meant to be helpers, they’re not magic.
Now, you can still use Chrome Inspector when you’ve activated Preview. And there is your code. The structure you’ve been defining, the custom code and custom fields you’ve been adding using the designer. all of it. And… it’s clean, it’s very understandable, even the proprietary classes that Webflow use make sense. And they’re predictable, and limited. Already way better than any of the big CMS I had to work with (not better, WAY better).
Not only using Webflow is like creating HTML and CSS, but visually, but it so respects everything that you get better at web concepts themselves. You do get better at HTML and CSS when you use Webflow.
For all of the reasons explained above, there is no difference of facing a situation with manual code than facing it on Webflow: an issue is resolved the same way: inspected in Chrome, solved in WF or code. Same, same logic, same efficiency. Situations were you have a bug because of Webflow, a bug that you can’t fix with HTML and CSS, are rare. The proof is that you can see users solving other users issue on this forum, every minute. Look at the solutions. Not so much as Webflow solutions but HTML and CSS. Users here constantly link to Stack Overflow, CodePen, W3C.org. Are those site talking about Webflow? No. HTML, CSS, JS and all that stuff.
They’re limited, but in my quite experimented opinion, they’re well defined. Yes that’s true that the wait for an larger one starts to be long. I could use an extra one in the like of 1200, 1440, for all of my projects. But I cope with this absence very easily, by crafting my own container, that behaves elastically between 1200 and 940. Still, I’d like to have a new one supported by Webflow, with the extended grid that comes with it. And the grid is maybe one reason why we still don’t have the extra breakpoint: the grid is very well managed in Webflow, not a lot talk about it but the components makes working with the grid very easy. The new breakpoint can’t happen in a snap, I’m sure there’s a lot to think about before bringing the feature.
It all depends on what you do. I can see some cases where hand coding can be really fast, but doing what I do with Webflow, spending time on every detail, refining every motion, fine tuning styles and make them behave neatly for each breakpoint, playing with conditional visibility on complex elements to procure the UX you wanted and not only what’s left as options to you… that I can’t see being more efficient by hand coding than visually designing.
I don’t see WF allowing touching the code in parallel of the designer anytime soon. What would be the point? Pinegrow allows this and it comes with limitations: that’s the reason Pinegrow isn’t on par with Webflow when it comes to visually edit/build a page.
I don’t even know what my point is here. All your fears, I had them. And I was skeptical about visual editors. They were all magic and buggy. I wanted to do too serious of a job to use any of them. Webflow wiped those concerns. I could develop what I want, visually. And the kind of closed ecosystem where you’re hosting on Webflow, in the end, made me concentrate on the design and pay a very small fee for all the servers and maintenance tasks that I didn’t want to do and that I was doing poorly anyway.
All I say is give it a serious try it’s worth it.