В чём основная концепция использования RxJava?
Концепция Rx заключается в основном в том, что существуют потоки данных внутри приложения. Эти потоки где-то начинаются (create) и где-то заканчиваются(subscribe). 
Про наборы данных - не знаю, скорее нет. Например, может быть бесконечный Observable, следящий за БД. Когда вы к нему подписываетесь, он эмитит текущее состояние БД, когда оно изменяется - эмитит ещё. Переподписка для этого не нужна.
То, что вы говорите про Observable, на который вы подписываетесь и работа идёт вне зависимости от этой подписки, это называется "горячий" Observable. Это можно сделать, но немного непонятно, зачем именно для сети нужно такое поведение. Зачем нужен выполняющийся запрос, если на его результат, возможно, никто больше не подпишется? В такой ситуации полезнее "холодный" Observable, который начинает запрос при подписке и отменяет его при отписке.
Далее, насчёт ввода с клавиатуры. Смотрите RxAndroid, и, в частности, RxTextView. В этом случае абсолютно то же самое - пока никто не слушает, следить за клавиатурой не нужно. Когда появился подписчик - начинаем слушать. И в случае именно андроида нет возможности установить несколько листенеров на одну вьюху, потому не удивляйтесь, когда дважды вызвав RxView.clicks(button).subscribe(Log::d) на одной кнопке, обнаружите, что эмиттит только второй Observable, а первый замолчал навсегда.
RxJava - это библиотека для реализации реактивного стиля в java
реактивный стиль вещь похожая на более известный функциональный стиль программирования. 
выражается он в следующем
есть поток данных, мы применяем к нему некие преобразования и получаем новый поток.
например
(поток запросов в сеть в виде адресов страниц)-> операторЗапросаВСеть -> ОператорПарсинга-> ОператорФормированияДатаОбъектов ->(отображение на экране)
Популярность в андроиде, думаю, приобрел за счет простоты работы с многопоточностью. По крайней мере первые примеры применения в андроиде rx обычно про это.)
вообще, это немного другой способ мышления. отличный от процедурного и ооп.
есть источник, есть получатель и много преобразований.  
источник это observable, получатель это subscriber/observer . преобразования это разного рода операторы или их цепочки.
В этом случае мы понимаем приложение как нити потоков данных. такая схема бывает проще чем схема из объектов. иногда.
конечно, мы можем применять и гибриды из этих парадигм.
вообще, это стоит попробовать. возможно она очень вам близка по стилю вашего мышления.