Yes, you’re correct here. Sometimes you’ll build with multiple views over the same data and do the union of the views or have one view you query multiple times and do the union or difference. There are some use cases where this works out great-- typically the aggregation kinds of cases-- but others where it requires a lot of work to get to what you describe in the SELECT statement.
It’s worth noting that in order to have that SELECT statement execute quickly, it too will require multiple indexes (which are like views). One on first_name and one on age. SQL will “fail back” to just scanning all of the data though. It’s not exactly the same, but the steps are sort of the same if you’re implementing it in views. The burden is higher on the application code for sure-- this could be good or bad.
Also note that N1QL (which is in our 4.0 dev preview) gives you something closer to what you’re describing there without the typical relational database tradeoffs of needing to have a fixed schema and not being able to scale. You can define indexes on fields in the JSON documents.