Splitting a monolith into microservices is going to take time. That's probably acceptable though, so let's ignore that.
Making applications reactive is probably worth the effort. The non-reactive applications are probably spending quite some time waiting on systems like MongoDB or other endpoints. By switching to reactive you can get more out of the applications that support reactive from end-to-end. That includes MongoDB and REST calls. (Not sure about
SOAP, but you don't want to do SOAP anyway.)
I'd go in two phases. One phase is splitting up the application into microservices. The other phase is switching to reactive microservices. You could do these two phases in either order, but doing them in this order allows you to more gradually do the reactive migration. Otherwise, there are probably lots of components involved that need to be migrated together due to internal method signatures changing. If you do it after the split, you can do the reactive migration one microservice at a time (or perhaps some in parallel if the capacity allows it).
Another advantage of the reactive migration after the split: Microservices that use non-reactive back-ends (e.g. RDBMs) can simply be skipped. Sure, you can add webflux etc, but there will still be waiting involved at the back-end layer.
