Hi,
content views are mainly there to manage your content, not to do some other arbitrary stuff using them (which can be done, but that is not the main purpose).
Mainly, content views are used to:
a) Group content (primarily products/repos) into managable units and then only assigning one (maybe composite) content view to your hosts instead of assigning every repo yourself.
b) Freeze versions of your content and then roll those frozen versions through your staging environments (like dev, testing, production) to make sure you do not get faulty/incompatible packages installed on your production machines just because somebody hit yum update.
You can in fact bypass all this and use the plain unmanaged repos directly via http, but that cuts a lot of the management potential of Katello and subscription-manager. If you would favor some further reading how this works, I did a somewhat extensible writeup here.