If the majority of computer aids turn off, the plane doesn't simply drop out of the sky. It reverts back to a more complicated, but human-controllable, vehicle.
From the article (and who knows how much Bloomberg understood) the active-active sounds more like recognizing, not recovering from, errors.
Which isn't the worst idea. Pilots being, well, pilots.
So you're asking the pilot to, in the midst of some other failure, to start flying a weird plane they ever flown before. You could solve that problem by training all your pilots in this BUT this solution is very expensive, so expensive the airlines might just demand their money back instead. And that wouldn't be a solution for Boeing.
And now, the FAA (or EASA) might just mandate that anyway.
I wouldn't be surprised if CAAC refuses to ever recertify the 737 MAX, especially if a trade deal isn't struck.
It's not my favorite solution for every application, but it's a good tool for a handful of situations. And it's a good way to avoid having to think about picking who to trust with only two sockets. There are other approaches, of course. For example, if your system can afford more than a couple clock cycles of latency (e.g., if you don't believe you can crash a plane with a couple milliseconds of control error) you can do the same thing with well-designed software and a bit of extra hardware. It gives you more freedom since there's more hardware to buy, at the expense of engineering and test effort to prove that your solution does what you want.
Doing this over large physical distances also adds some challenges. There are debates around dedicated signal wires direct between control centers vs data networks. Every situation is a little different, so there aren't really easy answers that you can swoop in and prescribe as best-practices. In general I find that people are more-skeptical of packet-switched solutions (e.g., Ethernet) than I would be. But most folks are also better at reasoning about the failure modes there than they are at thinking about the lower-level issues that Ethernet solves for you. And of course there are tons of different signaling systems - not just Ethernet - to consider.
Consider just a few different possible applications and the constraints that they impose. A car has less severe failure modes (many crashes are nonfatal) but less freedom in time. Your trajectory is simply more cluttered. A passenger plane has dramatically more energy, so failures are typically more severe, but you have a lot more time to deal with them because your trajectory is empty (much of the time, anyway). And if you're sane, you've designed it to be passively aerodynamically stable because twitchy maneuverability isn't critical when you're not a fighter jet. A rocket is a different animal altogether. Those are often rigged with self-destruct explosives, and you don't really get much time to change your mind if you erroneously choose to trigger them. Plus they're typically less stable (performance is more dear, gravity isn't helping you, and purely aerodynamic solutions don't take you outside the atmosphere) and are thus more dependent on their control systems.