For the purposes of this post Drupal is a content management system to produce web-sites (other use-cases are available ;)).
Some opposition to the major re-factoring of code for Drupal argued the new code-base contained too much abstraction.
The abstraction argument, I didn't get it. Abstraction from what? Abstraction from the internals of Drupal?
The main losers in the re-factoring of code from D7 -> D8 are the those of us who have invested a long time learning those internals and 'Drupalisms', I can understand that, I have learned a lot of this information that will become worthless. That is true of so much else over my time as a developer though and I am more than compensated by the expansion of the new things I am learning into other related technologies and being able to bring things I have learned elsewhere into working with Drupal 8.
I use Drupal to manage content and build websites, Drupal in itself is not a means to an end.
For the longest time however Drupal has been a major abstraction from the front-end and that has been both a blessing and a curse.
The various complications and varied expectations over layout and content that have evolved over the years with the Web can even be catered with via imaginative use of Views and Panels (with a whole host of magical configurable layout thingies etc.). Or perhaps a theme that implements a framework or a grid layout with a gazillion themes settings.
Drupal 8 should make this experience even smoother, although right now you might be missing some of your favourite contrib. modules.
With enough enough modules, themes, etc. perhaps you don't even need any front-end development if your requirements are not too custom right? But then Drupal becomes a machine replacing the front-end developer, a big ask, especially with fast pace of evolution in this business.
For some back-end developers who are more interested in content structure, transfer, APIs to other systems as well, all is good too, a front-end is better than no front-end and they may not be so focused on front-end anyway.
If you are a front-end developer, you may well be at the place where evolution is happening fastest. A few years ago you didn't have linters, pre-processors, frameworks, package managers etc. etc. There is always more to learn about UX, accessibility, always new devices and different ways of viewing the same page.
In many places there is no longer a ridiculous system of 'drawing webpages' in Photoshop. Wireframes and HTML prototypes are used and if you have the skills and knowledge the prototype is largely production standard anyway.
So when you are looking for a system to manage content, to make that prototype dynamic you want a tool to help you fill in the hard-coded bits. There are frameworks and systems that will let you do that, using the code and techniques that you know to 'frame the content' (they may not be quite as good as Drupal at managing content however).
When you come to Drupal you may hit a wall! 'Drupal is the king of content my young Padawan'. 'But how.. what ... uggg I didn't write that...., which hook, sorry HOOK errr hook_this_HOOK, help, theme.. Theme THEME.
"Don't worry young Padawan, don't think of the Drupal learning curve as a line, more like a .... cinammon swirl'."Why are you trying to do that by hand anyway? Use a micro, mini, panelizer, panel, view pane, custom page context, it will only take you a day (or three) to configure that bit in the admin section".
"It didn't wooooork!".
"Tut tut did you pre-process it?".
"HOORAY I finally have it!"
"Not so fast young Padwan, Drupal coding standards you have ignored!!! tsk tsk tsk".
Somewhere in the middle
And of course there is everything in between, every shade under the sun. Themes and approaches that strip everything back that Drupal so generously gives. Front-end developers clinging precariously to what Drupal outputs, enlightened souls prepared to help all, and jealous guardians of the knowledge they have obtained whilst travelling though the 'cinnamon swirl learning curve'.
Well Drupal 8 is different, I don't quite have my own personal answer to what comes next yet but getting there. Twig, common approaches, not invented here etc. should make everything different, but a lot of what I am seeing out there still seems to have a pre-d8 mindset behind it.
Not very satisfactory I know, I can tell you my goal. It is simply to have an approach, some examples, documentation and a plan that would enable me to introduce D8 into a skilled agency and for people to be productive in days, and for a large project to be succesful with only a minimal amount of 'specialised' Drupal expertise added to the project after that.
Not much to ask?