What is the reasoning behind only making change streams available on replica sets?
Change streams implementation is based on the oplog, which is only available on replica sets. Another reason is that a replica set contains a superset of the features of a standalone node, and is the recommended MongoDB deployment for production applications. Hence, it makes sense to implement the change stream feature based on the recommended production deployment topology.
Another major reason is that change streams will output documents that will not be rolled back in a replica set setting (see Rollbacks During Replica Set Failover), so the use of majority read concern is a requirement.
Note that change streams are also available in a sharded cluster, and also a single-node replica set (i.e. a replica set with only one member, although this setup is generally not recommended).
The high-level description of change streams is available in the Change Streams page
The design of change streams is outlined in SERVER-13932.