As with any programming concept and languages, almost every benefit that is gained introduces drawbacks. Some of those drawbacks can be solved, and others we just have to live with. At the end of the day, it's all about picking the right tool for the job and in some cases, the spreadsheet/reactive model is the right tool.

Spreadsheets are computer programs where the typical user doesn't usually care about the problems you mention as long as he gets the correct results.

The pros and cons I had from my reactive programming experience are:
Pro 1) Terse code: My typical defect/kloc remained about the same. So by using about 10x less code to do the same job, my defect count went down proportionally.
Pro 2 ) Live development: No need to stop/compile/start to change a rule, so it's possible to view the result of a rule change quickly. (this also leads to Con 1: Capacity to screw up)
Pro 3 ) No need to repeat formulas: Applying a formula to all the rows in a spreadsheet is tedious.
Pro 4 ) Complex Relationships: It's quite challenging to implement complex object relationships using spreadsheets as each object requires its own worksheet.
Pro 5 ) Data Visualization Tools: Reactive rules encourages developers to clearly layout their data and a good tooling suite can allow developers to visualize everything.

Con 1 ) Capacity to screw up: With live rule editing, a mistake in a rule could get evaluated instantly and potentially corrupt the application data beyond repair. This can be partially solved by good development practices such as taking backups during development.
Con 2 ) Fan Out: As the parent mentions, how many rules are triggered on a data change? This can be solved this using static analysis of the rules to figure out a triggering graph.
Con 3 ) Latency/Synchronicity: A good infrastructure can enable developers to define rules that synchronous, asynchronous or delayed execution. It's also possible to have an infrastructure that allows developers to monitor the cascade of execution. However, each change is executed through event triggers. A large number of changes leads to a large number of events which adds overhead. It wouldn't be a good idea to program a video game with this for instance.
Con 4 ) Large Data Set: Changing a reactive rule on a large data set might lead to a chain of event that takes a large amount of time to execute compared to a customized SQL script that would perform the change in a single batch.

A few years ago, I was curious to know how reactive programming would work on object oriented programming so I wrote an open source tool that tries it out using Java to define the reaction rules:

http://deduced.sourceforge.net/

I liked the amount of functionality I could get in just a few lines of code. Even the user interface was generated by reactive rules.

The thing that puzzled me the most with this tool is the lukewarm reaction of most developers who looked at it even when I proved that it could do things in about 10 times less code than a typical OOP solution.

The way I tried to solve this is to make a tool to program objects with spreadsheet styled rules in java that just execute themselves when they need to.
http://deduced.org/

The real deal can be fun.