Something is "available" or not depending on the observer and point of view. Users should be able to position Sentinels accordingly to the kind of failure detection they want, and usually where the slave are is not an objective point of view (that is instead where clients are usually).
Position, number of sentinels, level of agreement. Change this three elements and you can create many kind of setups.
About operations: Sentinels are designed to monitor other sentinels automatically and are as simple as possible to operate.
I don't disagree with allowing that flexibility, but letting Redis instances do dual duty would greatly simplify things for some really common types of deployments. It's awfully nice with Mongo to just run three members and get a pretty decent failover feature for "free", versus having to worry about maintaining an entirely different set of processes.
As to MongoDB, in case you only have two members in a replica set, you add an arbiter, not strictly three members.
An arbiter is indeed a lightweight mongod process that doesn't have storage, and should be added to break the tie when you have even number of members. I like the MongoDB's design, and it is probably optimal for 99% of use cases.
There are three key concepts: Split-brain, Quorum, and Fencing. I find this article fascinating.
Oh I agree with you, I was really just asking for the ability to run dual mode daemons. Companies who host these things for people might appreciate the option. :)
Position, number of sentinels, level of agreement. Change this three elements and you can create many kind of setups.
About operations: Sentinels are designed to monitor other sentinels automatically and are as simple as possible to operate.