Because it's not a good stack.

MongoDB is hard to use right and many people use it wrong and for the wrong kind of data:

It has no support for real transactions. $isolated can only cover a single collection and even then doesn't support rollback when a command fails and only covers a single query. You can use two-phase commits to address some situations but ultimately this means you will corrupt your data if you treat your database as if your multi-command actions (e.g. look up a document before deciding to interact with it) were transactional.

Joins are extremely costly. The workaround for this tends to be that people rely on embedded documents, which just means nested data. When that data represents something with relations, you'll end up duplicating data, which means you no longer have a single source of truth. Combined with the lack of transactions, this means you can end up with two copies of the same data that disagree with each other. But even without that it means updates become costly because you effectively littered your database with distributed caches, all of which need to be updated whenever the original data changes.

If you just need something that lets you store and lookup data by ID, a key-value storage like Redis is the better choice. If you want powerful queries, an SQL database like PostgreSQL. Or use a more apropriate NoSQL database like RethinkDB or ArangoDB.

Express is a good alround framework that is great if you need something to get started or even build reasonably complex websites or APIs. But it's not the best fit for everything. When combined with a frontend library like Angular it is often used to build HTTP APIs. There are more specialised libraries like Hapi which are more full-featured and better suited for this task.

AngularJS (Angular 1) is complex. It is full-featured but it carries a lot of conceptual overhead and idiosyncracies and overall ugliness:

It brings its own HTML-based template language disguised as custom HTML attributes and elements. Unlike a regular template language they then go on to live in the DOM. Because of this they make server-side rendering of AngularJS (Angular 1, not 2) apps practically impossible because of the next point:

Although a good chunk of the state and logic lives in the DOM, it's still a JS app and still relies on state stored in variables outside the DOM. This state however also includes various instances of controllers and whatnot, which can't be meaningfully serialized. On page load AngularJS need to recreate everything. If there are unexpected references in the initial DOM (as in server-side rendered markup) it will blow up.

It wants to control everything. Because it was built around the idea of two-way data binding (which has recently fallen out of favour) but doesn't want to complicate your life with getters and setters, it can't know when the state changes and thus has to look whether something changed. All. The. Time. This is especially problematic when something asynchronous happens (i.e. when it doesn't know to look), so it brings its own replacements for AJAX and even its own promise library.

It makes the most frequent thing too damn hard: components. AngularJS originally only had directives. Directives are what makes your markup actually meaningful to your application. They bind values and event listeners. Before component, directives and components were the same thing. Even now the two are confusingly similar and component is still too damn complicated compared to e.g. React because it tries to do too many things at once (e.g. managing the global state tree via bindings).

And lastly the jargon is mind-numbing. This is okay if you are used to frameworks that require a thick manual but incredibly painful in the JS world, especially compared to alternates like Ember or React+Redux. Everything has a name and every name refers to an actual thing you either have to write, have to use or be aware of as soon as you run into problems. What is a service factory? What is the linking phase? What the smeg is an isolated scope? You should know these if you want to do anything non-trivial with AngularJS.

AngularJS is great for rapid prototyping where you are mostly concerned about the design and need something that roughly works. If you want to build real-world applications with real user requirements better just use React+Redux. Or if you don't want to spend energy on picking the various bits and bobs that React doesn't give you (or if those Rails devs in your team keep pestering you), pick Ember. Did I mention that you'll be hardpressed to find a major real-world flagship application that makes extensive use of Angular? Netflix, Instagram and Facebook all feel comfortable putting React in your face.

Node ... well there's really not much to say about Node in particular except that it's new, most major companies likely have reservations about letting their frontend teams work on the server and have server teams that don't want to learn JavaScript and instead stick with what they know (which is usually Java, C# or maybe Ruby).

Full disclosure: I am a contributor to ArangoDB but these opinions are purely my own and not approved by or representative of the ArangoDB project.

i guess, they need to do some heavy data migrations, refactor their infrastructure, hire new devs, fire some devs and train them.

Because it's costly. Big companies usually don't put effort into migration legacy applications to newer Technology until its clear the return of the investment and there is still risks associated with new Technologies. So they are fat and big and so moves slowly to brand new stuff.