RxJS and Angular, I'm not feeling it

I read an article by on creating custom Closure builder for Angular, and apparently the "Architect" (yes, that's the name of the system) relies heavily on RxJS for consistent API.

Build Angular Like An Architect (Part 1)

Stephen Belovarich ・ Apr 2 '19

#angular #javascript #devops #webdev

Yet again, I'm thinking how much easier people would have it if we (Angular community) were ok to use Promises where they made sense. Here's an example snippet from the article:

return of(context).pipe(
    concatMap( results => ngc(options, context)),
    concatMap( results => compileMain(options, context)),
    concatMap( results => closure(options, context) ),
    mapTo({ success: true }),
    catchError(error => {
      context.reportStatus('Error: ' + error);
      return [{ success: false }];
    }),
  );

This is what it would look like with promises (in 'async' function):

try {
  await ngc(options, context);
  await compileMain(options, context));
  await closure(options, context);
  return { success: true };
} catch (error) {
  context.reportStatus('Error: ' + error);
  return { success: false };  
}

(This is just async function for handling one element from the stream, so you need a Promise.all in some top level to do the loop).

It's clear that the hotshots doing RxJS day in and day out can sling those concatMaps and mergeMaps in their sleep, but for an average developer - can you take a good glance at that RxJS and tell whether it's correct or not? Is the right operator being used? If you are speculating that a bug might be in that area of the code, how fast can you read and replay the flow in your head?

It is pretty clear that the wider web developer community already opted for Promises and async/await, how long does Angular community plan to go their own way?

(Before you ask, yes, I know Angular itself is built on RxJS - I have three pages of that in the call stack every time I hit a breakpoint).