Bad management is when your company evaporates because you make one bad call.
Management gets points for surviving and then fighting back despite being wrong. And when you look at Intel's history, there are few companies on the planet who have managed to do that multiple times. They have a good mix of people who know what they are doing technically AND people who do whatever it takes to keep the company from sinking when those bad technical calls happen.
If Nvidia survives whatever their next bad call maybe expect them to start looking more and more like Intel.
That's a pretty low bar!
AMD could never made the same gamble as Intel did for Itanium. There's a long technical argument as to whether the world is better off in a technical CPU design sense because of that, but I disagree that it's necessarily good management of Intel that's allowed it to recover from disaster.
The best management can play the hand they're dealt perfectly and still lose. However bad management can play the best hand poorly and still win.
CUDA's sweet spot lies between embarrassingly parallel (for which ASICs and FPGAs rule the world because these are generally pure compute with low memory bandwidth overhead) and serial (for which CPUs are still best), a place I call "annoyingly parallel." There are a lot of workloads in this space in my experience.
But if you don't satisfy both of the aforementioned requirements and/or you insist on doing this all from someone else's code interfaced through a weak-typed garbage collected global interpreter locked language, your mileage will vary greatly cough deep learning frameworks cough.
Finally, it doesn't matter who's doing it, marchitecturing(tm) drives me nuts too.
Controlling the language certainly helps Nvidia's economic moat.
Arguably one of the things that Nvidia really got right was learning from those past failures at other companies and making it easier for developers to utilize the platform starting from a standpoint that they were familiar with and helpfully nudging them towards what would run fast in parallel.
I think the big disconnect is thinking they had to make people rewrite code. CUDA often targets entirely new codebases, and in some cases new types applications.
The "rewriting of code" is mostly for things like AV processing and codecs where there was such a sellable benefit in performance it would have been insane for them not to invest the effort.
Intel was doubly hindered here, because they wanted everything to use x86. Intel had trade secret and patent protections from competitors, and a critical mass of marketshare.
Parallel programming was something that had to fit into that "x86 for everything" mindset rather than being a separate/competing technology to x86. The company that pushed winmodems and software sound cards wasn't going to be able to lead the disruption there.
Only now, more than a decade later they realize their mistake and try to correct the juggernaut's course. Such glacial mistakes in this industry can cast death blows to even the largest entities.
They drowned out Pat Gelsinger late 00s, then Justin Rattner and many others Retired in early 10s, the rest is history.
It's not that Intel doesn't have people that recognize the issues, but rather the people who do have that foresight are drowned out by people who don't realize the game has changed. Intel, to be fair, does have the best autovectorizer--but designing vector code from scratch in a purpose-built vector language is still going to produce better results, as shown when ispc beat the vectorizer.
But Nvidia can also get drunk on its kool-aid, just as Intel has been. Nvidia's marketing would have you believe that switching to GPUs magically makes you gain performance, but if your code isn't really amenable to a vector programming style, then GPUs aren't going to speed your code up, and the shift from CPU-based supercomputers to GPU-based supercomputers are going to leave you happy. There's still room for third-way architectures that is anyone's game.