I'll do my best to not turn this question to an "opinion-based" one, but it's a great effort for me!
SharePoint 2003: the story begins
In the beginning (SharePoint 2003), we could develop Web parts and event handlers.
We could do that from Visual Studio, and even if there was no integrated deployment mechanisms, we only had to deal with a very few XML files and 2 or 3 commands with stsadm to package and deploy.
SharePoint 2007: the farm solution model
Then came SharePoint 2007: it brought a mechanism to deploy and update properly artefacts (features and WSP solutions).
A lot of new artefacts was also made available: custom actions, control templates, feature event receivers, content types, ...
There was no good tool in Visual Studio initially, but we could create a simple "make file" to automate the build without external tools.
Or we could use WSPBuilder, from the community, that was perfectly integrated into VS (even though it had some drawbacks).
Finally came Visual Studio 2010 where everything was directly integrated: a new project type to support almost everything we could do with SharePoint + complete package generation + debug tools + all from the UI.
We were efficient, SharePoint was an accelerator for developments.
SharePoint 2010: sandbox solutions
And then SharePoint 2010, the best SharePoint version IMO (we had all the best from the product, it was stable and reliable, users were efficient with a consistent UI accross the Office range, and no crappy trendy features in it).
The WSP package concept was there to stay. Developers knew it and were efficient coding in C#/ASP.NET (and a bit of XML if they wanted).
Only known/mastered technologies. Very few bugs.
Oh, yes, there were bad applications developed in SharePoint. But less and less. And applications were actual applications to deliver actual value to businesses.
If you had enough experience (let's say 1-2 year) with SharePoint development, you could be very proficient and deliver a real-life professional application in a few days or weeks, much faster than with pure ASP.NET.
The model was good enough for Microsoft to create the "sandbox solution" concept. It was a step to the cloud: Microsoft didn't want developers to deploy crap on their servers, but they also wanted to allow customizations.
The idea was not that bad, since sandbox solutions allowed developers to re-use the exact same concepts (WSP, features, artefacts, server-side API) but with some boundaries to avoid messing the cloud servers.
At that time (3 years before add-ins), Microsoft clearly promoted the sandbox solutions as the new black.
2013: The Cloud.JS
WSP were evil.
Sandbox solutions were eviler than the evil.
Apps were the new black. But not a good name, don't know why. Let's say Add-ins instead (to add some confusion).
Forget everything you learned.
Forget being efficient coding in C#.
Forget all known concepts about SharePoint.
Only to explain the authentication mechanisms to good developers, I spend 2hrs in a training class! How can this approach be fast when you draw 10 arrows on the paperboard just to show how the user is authenticated with your app?
Microsoft even announced quickly the "auto-hosted" model was to be retired a few months after it was released.
Some software vendors tried to port their WSP applications to the new app model: they had to cut half the features of their products, or more.
In 4 years, 1135 apps have been published in the official store, including a lot of "hello world" apps from testers, weather widgets and carousels.
But that was definitely the way to go, as per Microsoft. They also convinced a lot of other people to push evangelisering materials. One among 1000s (note: I challenge every "reason" from that article).
My first question is: in 4 years, did you ever see a complete business application properly deployed in the add-in model?
If yes, what was the cost of the development compared to other technologies (pure ASP.NET, pure PHP, "old-fashion" WSP...) in your opinion?
As per this recent post from @PatMill_MSFT, we even learn from Microsoft that "5000 lines of pure js is a lot".
Also, apparently no-one can answer a simple question ("simple" in the sense "could be easily solved in the old times") about authentication delegation and access to data in Office 365 (I raised the question on this site, but also to a lot of consultants, Microsoft employees, etc.).
2016/2017: SPFx "release candidate"
But that's not the end of the story.
We now learn that "There are a couple of downsides though" with add-ins. No kidding?!
So, something new to overcome the situation: SPFx!
OK, let's see.
Instead: NodeJS, Gulp, Yeoman, React, WebPack, etc. And no more integrated environment like Visual Studio. So old-school. All MS-technologies developers know/have Visual Studio, so let's dismiss it now! To install a clean dev environment, you have to setup 5 or 6 modules, use many command lines, mind the versions ("If you have NodeJS already installed please check you have the latest version") and pray for everything to be compatible with the latest versions. And they don't even mention how to develop in a team, how to easily version-control your sources, etc.
Also hope you don't mind your Web designer cannot access the HTML code easily.
For a "simple" old thing such as localizing your solution, something that should have been solved decades ago: nothing to help you, apart from reading a 33-page article that explains you you have to maintain a bunch of different files in sync manually. And that's only one example among many.
Let me skip the still-not-solved-even-with-the-amazing-Yeoman-tools-versioning problem: SPFx is not the announced silver-bullet even in that advertised area (I spent 2hrs solving problems while upgrading from SPFx 1.3 to 1.4).
Oh, wait, do we count the brand-new Graph API while it's not that compatible with the brand-new SPFx?
So, my third question: if you had to create a new application for a customer, "from scratch", would you go with the "new shiny" SPFx tools?
Do you think developers are efficient with it? Is it sustainable? Are your teams comfortable with all these "technologies"?
And an opinion-based one: isn't Microsoft goind crazy with SharePoint development, as I think? Are we supposed to be confident we have found the (SharePoint dev) silver-bullet with SPFx?
EDIT: some more details about my thoughts, following some points raised in answers below
I'm not afraid of changes. I'm afraid we are forced to use new technologies just for the "fun" of using "edge" technology and fancy names because a new Product Manager at Microsoft decided to upturn the tea table.
It's like if the "Cloud" is encouraging Microsoft (not only) to trash all the long trust-relationship with developers in order to please the marketing guys.
(I see at least 3-4 reasons for that: 1. It's technically easy for MS to push and test changes to the Cloud, so they try a lot instead of long-term thinking ; 2. They're not a real leader anymore in the industry, so they run after the newest technologies just to "stay in" ; 3. There's more turnover in enterprises ; 4. Managers are less and less technicians)
Releasing (and soon after dismissing) new technologies without a long-term vision may not be what we expect from a dev company like Microsoft.
Changes is good when it brings actual value.
As a developer, I don't have to accept all changes without questions. My job is also to be efficient, to challenge new technologies, and to help my customers building the best software (i.e. bringing value with the cheapest, maintainable, sustainable, evolutive piece of software...)
What's the value of spending 1+ day to setup/understand your dev environment for your team while all developers are familiar with Visual Studio? A dev environment that may break as soon as a new version of one of the involved tools is not supported anymore/releases a new non-compatible version/is abandoned for another one? This is highly probable when the tools are not owned by Microsoft nor built with SPFx in mind!
What's the value of running 5 or 6 modules before packaging an app if a failure may occur at every step?
And above all: how can we be confident we're now with the "good" (i.e. lasting at least 2 or 3 years!) framework while so many concepts/frameworks that were known to be the silver-bullet are now ~dead (sandbox solutions, autohosted apps, Graph API being non-compatible with SPFx, Angular 1, Grunt, XML, SOAP, Apps and IFrames, SharePoint ribbon, UI tiles, SP list dialog boxes... to randomly name a very few of more or less importance).
And in response to @florian-leitgeb:
Maybe the young developers can't get the big picture of these constant new-framework/new-tool-on-the-block changes. But imagine: can you say "go with the flow" to someone who invested in Silverlight or auto-hosted SP Apps or XNA or Angular 1 or InfoPath or Workflow 1.0 or even SP REST (Graph is the new kid here)? What are the odds Gulp and SPFx won't be that hype in 2 years from now? What will I tell to my customers when they understand the great-tech we used 2 years ago is obsolete and the project has to be re-booted? Microsoft used to "develop things" in an integrated and long-term way... not anymore IMO.