Por qué return await en JS no siempre es malo, sino todo lo contrario: es lo correcto

Algunos desarrolladores de JS se hacen los listos y dicen que en vez de:

return await someService.doSomething();

hay que escribir:

return someService.doSomething();

O sea, si una función async devuelve una promesa en su return, el resultado de resolver esa promesa se convierte automáticamente en el valor de retorno real. Es decir, las promesas se "desempaquetan" de forma recursiva.

Todo esto suena bien, pero hay un problema bastante serio. Miren este código:

// Técnicamente esta función devuelve una promesa,
// pero en realidad lanza un error
async function fun1() {
  throw new Error('Hi from Famabara!');
}
(async () => {
  try {
    return await fun1();
  } catch (err) {
    console.log('Error catched!', err);
  }  
})();

Aquí todo va bien, el error se captura en el bloque catch. Pero si lo escribimos así:

async function fun1() {
  throw new Error('Hi from Famabara!');
}

try {
  (async () => {
    try {
      return fun1();
    } catch (err) {
      console.log('Error catched!', err);
    }  
  })();
} catch (err) {
  console.log('Error catched!', err);
}

¡entonces ninguno de los dos bloques catch captura el error! Esto es una desventaja tremendamente grave. El error simplemente no se puede capturar de ninguna manera, a menos que uses el método catch() directamente sobre la promesa, si no escribes await.

En fin, la recomendación de no escribir return await es una muy mala recomendación. Directamente perjudicial.