Should subscribeOn and observeOn only be invoked by the final subscriber?
<p>The <a href="http://www.introtorx.com/content/v1.0.10621.0/15_SchedulingAndThreading.html">Scheduling and Threading</a> section of <em>Intro to Rx</em> says that </p>

<blockquote>
  <p>the use of SubscribeOn and ObserveOn should only be invoked by the final subscriber</p>
</blockquote>

<p>It also says that in an UI application, the presentation layer, which is normally the final subscriber, should be the one to invoke these methods.</p>

<p>I am wondering if the advice is solid, since I see some situations in which this is not convenient:</p>

<ol>
<li>For starters, I don't believe that the presentation layer should decide where an Observable coming from the data layer should be subscribed. In my opinion, the presentation layer should be unaware if the data is coming from a database, from a REST API, or from memory. For this reason, it's convenient for the data layer to call <code>subscribeOn()</code> before returning the Observable, passing the IO Scheduler or the immediate Scheduler as convenient.</li>
<li>If the presentation layer gets the Observable from some service or use case (which in turn gets it from the data layer) and this service decides that it needs to process the stream in some computation Scheduler, why should the presentation layer care about this?</li>
<li>What about a stream that is originally coming from the UI, so it needs to be subscribed in the UI thread. Then it will be sent to some service to do some work and finally come back to the presentation layer to be observed in the UI thread. That would require the UI stream to be <code>subscribeOn()</code> the UI Scheduler, then <code>observeOn()</code> some other Scheduler, and finally <code>observeOn()</code> the UI Scheduler. In this case, being able to invoke <code>subscribeOn()</code> and <code>observeOn()</code> only in the final subscriber would mean that the stream can only be processed in the UI thread.</li>
</ol>

<p>Is there some good reason why I should sacrifice the architecture of my application and ignore Rx's ability to easily switch threads by invoking these two methods only by the final subscriber?</p>