That's a great discussion out here! Let me put my 50cents. A lot of different topics are discussed, I have a lot of different thoughts and don't even know how to structure them. I'll try.

I think there are few reasons why Microsoft invent new approaches. And the main reason is moving to cloud. Consider image from here - SharePoint converged code base. They have plans to merge the code and one day in a future we will see the message from Microsoft - "Sorry guys, on-premise SharePoint deprecated".
But it's not possible to use farm solutions for manipulating with SharePoint Online, that's why apps, csom came into play. Miscrosoft tries to find the right and good way to provide us with an options to customize SharePoint Online, but that's hard thing to do, that why some attempts are failed or have some drawbacks (auto-hosted, code in sandbox solutions, iframes, etc.). That's like windows vista. From the other side the good point is that MS still think about developers and tries to find a way to do customization more efficient.

Of course all this changes are annoying. Especially when they are deprecated in a few years after announce. How to deal with that? You have either live with that or switch to new technology which is more interesting for you.
Is it good to move everything in a cloud? I think yes, because it's a tendency nowadays, it gives easier management, setup and configuration. less cost for IT infrastructure.

Also the fact that MS tries to invent something new and tries to follow modern tendencies is also good. I can't imaging if in 2017 we are developing ASP.NET Web Forms pages for SharePoint farm solutions. Everything is evolving and evolving really fast in recent years. How many js libraries you can name in 2007? I can say - only one, jquery. And today? From my POV staying at the same place today is like a death. And hopefully MS doesn't stay.

Also some thoughts on too frequent changes. I spoke with different web developers from js background (nodejs or web frontend). I'm also doing a lot of web frontend development. Today they are having the same problems with interoperability, numerous different modules and libraries, compatibility issues, etc. That's a total nightmare actually - just read this article. But you have to follow if you want to be on top.

For the questions:

My first question is: in 4 years, did you ever see a complete business application properly deployed in the add-in model?

Yes, I developed such application for SharePoint online - azure web app, jobs, storage, remote event receivers. The app helps generating different kind of documents and distributing on other sites. The project duration is around one year.

should I conclude that JavaScript add-ins are for applications less than 5000 LoC?

I don't think so. My POV - just write good, maintainable, modular javascript (typescript) and you are good to go.

if you had to create a new application for a customer, "from scratch", would you go with the "new shiny" SPFx tools?

If requirements allow me to use SPFx in order to solve any particular task, definitely I will go ahead with SPFx. I found SPFx might be extremely hard to learn without good understanding of basic concepts - es modules, typescript, webpack. Having all that background and angular 1 & 2 in addition I like the idea behind SPFx and will use it.