Not sure if Reactive Programming achieves this lofty goal, and buzzwords are always annoying, but I'd be wary of dismissing RP out of hand.
(I'm still undecided on its merits, by the way)
The issue is what tools you have to dig in when you're asked, "Why is this page taking 5 seconds to load?" With a traditional single threaded application there is the inherent simplicity that you can profile it, look at timings, and see where the performance went. With an asynchronous distributed application, you have to do a lot more work to start digging in.
The reason why this matters is that there are always some boneheaded performance mistakes. They would be trivial to fix if you only knew what to change. Without visibility, you won't be able to find where they are - you're just stuck suffering the consequences.
I'm definitely not saying that this is impossible. Far from that - Google succeeds brilliantly. But the kind of behind the scenes pervasive visibility that you need is an essential component, and it is not something that happens by accident or is trivially retrofitted on.
There you can see lots of data related to an application using Akka, including its performance and possible bottlenecks.
You can use it easily from the web browser, the only downside is the large amount of RAM used.
Edit:
How can you down vote an observation? Feel free to comment instead. I enjoy Scala, which is why I joined the course, but I thought the above added weight to the argument that Scala is too complex/academic/etc.
I agree that the exercise from week 2 (the epidemy simulation) was a mess. It was barely about reactive programming though. The mess was introduced mostly because the exercise has lots of mutable state. That the tests cheated, bypassed the API and mutated the internal state of the simulation didn't help either. But I assumed one of the aims of this exercise was to show how mutable state can mess things up, even though this wasn't officially acknowledged by the staff.
Your observation about Scala is unwarranted though. Nothing about the exercise's difficulty has to do with Scala. It's also not "too complex" or "academic". It's an extremely simplistic discrete event simulation of a disease, almost like a cellular automaton... How can this be "too complex"?
A lot of the head scratching was caused because the course is open to anyone. This is a good thing, but it also means a lot of people taking the course barely have the fundamentals of programming down. If you read the forums, a lot of people don't know how to write test cases or debug code, for example. These people would have found almost any non-trivial exercise in any language difficult.