Agree. Lots of money still being thrown at Drupal agencies.
The only thing you don't get for free with Drupal is a backend which you can speak to if you're deciding to go the SPA route later on.
Which, in my personal opinion, is a pretty stupid trend anyway. SPAs tend to grow to Java Enterprise levels of complexity very very fast, and things break All. The. Time. Not to mention you're putting huge amounts of work to the frontend, where you virtually cannot account for cross-browser behavior, people with multiple-year-old browsers... and people with devices older than two years!
Leave a Drupal project idle and unmaintained for a year, and you'll be able to pick up where you left it. Good luck doing the same with an AngularJS SPA - you might get away if you used npm shrinkwrap when you left, but the first npm update WILL kill your code with a billion possible places to fix.
Drupal is mature, and maturity is something that the entire Javascript development and tooling community is missing unless you stick to plain jQuery.
Stability and reliability IS a thing, especially in enterprise.
Go the hipster way when your target audience is hipsters, go the proven, old-school way when your target audience is enterprise.
edit: ad maturity of Drupal and support... D6 got released in 2008-Q1 and support ended in 2016-Q1. That's EIGHT YEARS of continuous support and security fixes, and I expect similar if not better support timeframes for D7.
Good luck finding a Backbone.js or Ember.js (and maybe even AngularJS) developer in four years from now; not to mention that during the entire D6/7 lifetime backwards-compatibility-breaking changes were a rarity in Drupal when all of the mentioned JS frameworks have had more than their fair share of clusterfucks stemming from bad design. Or just the tooling environment, breaking changes everywhere and (gut feeling) every month there's a new tool to learn or best practices revamped.
Wonder why PHP, server-side rendering and SQL is so prevalent? You can rely on buying a solution and having support and developers even in multiple years from now. Enterprise doesn't want ever-changing piles of crap layered in more piles of crap, enterprise wants stability and maintainability. And enterprise is where the money is, not some SV startup only surviving on VC or with 90% of its customers startups only surviving on VC.
If you want to ever have a safe upgrade path that doesn't involve months of testing then you absolutely need a type system, IMO. The only framework I've felt completely safe doing major upgrades on is Wicket - which, not coincidentally, is the only framework I've ever known to make extensive use of final classes and final methods (Java), to enforce that it's only possible to use it in supported ways.
Maybe I just have bad luck.
People see JS and throw their JQuery & some CSS developers at it. Or they use their backend PHP devs who've never written code that runs for longer than one request.
Either way you end up with code written by people who don't understand some of the fundamentals of UI programming.
Angular gets the worst of it because it's the most popular framework. It's exacerbated by the fact that Angular doesn't offer suggestions for a lot of common problems.
Proper error handling, sane state management, and keeping the codepaths short and easily grok'd is very difficult with Angular -- especially for larger applications. This results in blackholes where users find themselves in strange spots that are inescapable other than a full page refresh.
These are either developers dipping their toe into the front end after living in the back end of things their whole career, jQuery dudes hastily breaking into SPA development to stay afloat in an environment the submitted article exactly mentions, or simply lazy developers that couldn't be bothered due to tight deadlines/budget/whatever.
But if proper error handling, sane state management, and keeping codepaths short are actually "very difficult with Angular," maybe it's not the comprehension powers of the developers using it that are falling short.
A framework should be actively making those things easy.
React/JSX and TypeScript are a response to this and it's fair bit more pleasant when either of them are involved.
You are free to use jQuery in your theme (aka frontend code), or D3 for visualization, or any other JS stuff you may need. On a private project, I'm using a current jQuery, D3, and SCSS and it works quite fine for me.
The only thing in D7 that can be a major PITA is proper multi-language support, because it's a bit sparsely documented.