El bloqueo es malo, ya que ata un hilo en espera de una respuesta. Es muy malo en un marco reactivo que tiene pocos subprocesos a su disposición y está diseñado para que ninguno de ellos deben bloquearse innecesariamente.
Esto es exactamente lo que los marcos reactivos están diseñados para evitar, por lo que en este caso simplemente te impide hacerlo:
Su nuevo código, por el contrario, funciona de forma asíncrona. El subproceso no está bloqueado, ya que en realidad no sucede nada hasta que el repositorio devuelve un valor (y luego la lambda que pasó a savedQuote.subscribe() se ejecuta, imprimiendo su resultado en la consola.)
Sin embargo, el nuevo código aún no es óptimo/normal desde la perspectiva de las secuencias reactivas, ya que está haciendo toda su lógica en su método de suscripción. Lo normal es hacer una serie de llamadas flatMap/map para transformar los elementos en la transmisión y usar doOnNext() para efectos secundarios (como imprimir un valor):
stockQuoteClient.getQuoteStream()
.log("quote-monitor-service")
.flatMap(quoteRepository::insert)
.doOnNext(result -> System.out.println("I saved a quote! Id :: " + result.getId())))
.subscribe();
Si está haciendo una gran cantidad de trabajo con reactores / flujos reactivos, valdría la pena leer sobre ellos en general. Son muy potentes para el trabajo sin bloqueo, pero requieren una forma de pensar (y codificar) diferente a la de Java más "estándar".
