Just what your coworkers said, it's hard to maintain.

It still has it's application but it's quite hard to ultimately work with. For example, if something throws an exception, if you didn't setup the pipeline correctly it's stupidly simple to simply silently drop the exception all together.

And even when you haven't done that, it can be really difficult to understand why an exception has happened. You might be able to fairly decently get to the stage in the pipeline where the error came from, but working back to how the inputs got there in the first place can be really difficult.

More traditional programming is just a lot easier to work with. An exception getting thrown gives you a stack trace that gives a pretty clear picture of how you got to where you are at. And, putting in additional contextual information can make diagnosing everything a lot simpler.

I'll also just say, I find Rx (js, java, C#, etc) to be overly complicated in general. I'd suggest just trying some other reactive frameworks to see what I mean. Kotlin's Flow api is pretty good (IMO) and really makes a lot of struggles around learning Rx much easier to grok. I found that a decent part of what made reactive programming hard wasn't the reactive programming but rather Rx's implementation of it.

In practice, my experience is that it's mostly a lose-lose proposition. You have to invest in learning a bunch of same-but-difterent framework apis to do what the language already does natively. And in return, the code is more complex, and harder to debug, and so it has more bugs.

We once hired a very smart fellow to build out a media processing pipeline. He did with rxjs, but it wasn't scaling well. We tried to get with the paradigm for a bit and help scale it up, but flame graphs in profiler output were all crazy, and it was a pain to wire in timing traces, etc. We built a POC imperative version just to prove that we could indeed achieve the throughput we thought we could, and then we just said, well hey, this is faster and simpler, so... let's just go with this instead. And so we did.