Angular2: Service architecture + error handling

I need support for Angular2 service architectures. I am quite familiar with Angular2 but I don't see the best way to implement services, error handling and their connection with the components. I'm aiming at small-middle-sized Angular2 applications having not more than a few couple (<100) pages.

These are my main dilemmas:

1. RxJs Observables OR Promise/async-await functions (or theoretically callbacks, but no way)
2. Error propagation: handling errors in service OR in component
3. Results of a service call shall be available to everyone OR only for the caller

Let me write a few examples.

export class StuffService {
  constructor(private http: Http, private alert: AlertService) {}

  // 1. RxJs
  // 2. Handling error in component (caller)
  // 3. Results for caller only
  getAll(): Observable {
    return this.http.get('/stuff/all')
    .map(res => res.json());
  }

  // Subscribe for this to get the results
  stuffs = new BehaviorSubject([]);

  // 1. RxJs
  // 2. Handling error in service
  // 3. Results for everyone 
  getAll2(): void {
    this.http.get('/stuff/all')
    .map(res => res.json())
    .subscribe(
      res => this.stuffs.next(res),
      err => this.alert.errorPopup('Refresh failed'),
    );
  }

  // 1. Async-await (Promise)
  // 2. Handling error in component
  // 3. Update results for caller only; and it also updates the `stuffs` observable
  async update(item: Stuff) {
    let result = await this.http.post('/stuff/update', item)
    .map(res => res.json())
    .toPromise();
    // Auto-refreshing the list, each subscriber gets the update
    this.getAll2();
    return result;
  }
}

I'd prefer both the 2nd and 3rd solution.

A. I want to keep some data available globally through subscriptions (see stuffs in the example) because it prevents inconsistencies: whenever a component refreshes the list it gets updated everywhere. And it requires a single query. RxJs Observables fit to this concept perfectly.

B. Generally I'd prefer service-level error management, in this case: raise a modal error popup from the service. In most cases it is enough and prevents redundant error-handling in each caller. But what if we do need error handling in the caller? What if the service shouldn't raise the popup?

C. Some opeations should not affect anyone else besides the caller. It may succeed or fail, and it may affect the caller but nothing else. This is a typical use-case for Promises, RxJs seems to be an overkill in this case. Error-handling is also a question here: in service or in caller? (See previous point.)

D. Some operations do not affect anyone else directly but we should make an refresh on some other data -- and this will affect many other. See the update() operation: we should refresh the stuffs list after the update to get the changes.

E. Keep it simple as possible. This is not rocket science, only simple, efficient domain specific web architecture.

These dilemmas could easily lead to an architectural mess on the long run. I'd love to hear your opinions and best practices.