this is typically untrue. the genesis of libraries like RxJS is encapsulating repeated code responsible for properly handling async resources/transformations. without them, you would either repeat similar code everywhere, or end-up writing your own version for the organization. you don't need to take my word for it though, try replicating some of the examples on the website (or on learnrxjs.io) to see this for yourself.
> Locked into a libraries way of doing logic chains
this is a valid concern, though the other side of this coin is not using anything like express, angular, react, etc as they all have the same effect. the design of such libraries should typically be pretty flexible to be more facilitating than restricting, and its always a bonus if they are smartly restricting (discouraging programmers from making mistakes and taking away cognitive load of making choices that can be mostly decided beforehand, etc). core concepts of RxJS for example are so basic that there are serious ECMA proposals to adopt them into the language itself (Observables), much like Promises before them (which were initially promoted by libraries that are still around).
> Steep learning curve for new team members
this is specifically true about libraries targeting reactive programming. the issue is not actually with the libraries but with the paradigm itself, as it requires a different mental model of the flow of the code. this is part of the reason CONNECTIVE exists to begin with, to offer an interface reflecting a more intuitive mental model of reactive flows compared to RxJS, though still it would be a different mental model compared to traditional synchronous programming.
this learning curve however is something that I personally believe is unavoidable in the long run. you already need to adopt it if you want to be competent at prominent frontend frameworks like React or Angular, the latter of which incorporates and utilizes RxJS extensively and the former borrows a lot of the concepts. we already had to go through such a curve with transition to NodeJS for backend, where before you would mostly write fully sync one-request at a time instance codes and compensate by paying extra for the hardware, but now-a-days that extra learning-curve is no longer considered a deterrent.