Throughout Silverlight and WPF properties that are boolean values are prefixed with Is (almost all), for example:
IsEnabled
IsTabStop
IsHitTestVisible
In all other Microsoft frameworks (winforms, BCL, ASP.NET) Is is not used. What prompted their team to move away from the original naming convention - is it an evolution or a miss-naming that had to stick?
The Is prefix can give a hint about the fact that the property only has a get accessor, and, as Thomas and Rachel said, it's a bool. Skip the prefix if you intend to implement both get and set accessors and its type is other than bool.
Personally, I always try to prefix boolean values with something that adds a little more meaning (is, has, can, etc.). My usage comes from the following Microsoft guidelines:
Do name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value.
I don't believe this was always the case This wasn't always the case. Those practices date back to .NET 2.0. Before that, things were fair game. Cleaning up those names in newer versions of the Framework, however, would cause all kinds of headaches (hence some of the Framework code uses the convention and some doesn't).
It definitely makes things more readable though. Even using an example from your question. Which would you rather have?
// ambiguous naming, could mean many things
myTab.TabStop
or
// definitely a true/false value
myTab.IsTabStop
The Is prefix is part of the official Microsoft Framework Design Guidelines (this does not mean that all MS products adhere to it...).
Personally, I find it useful, if consistently used. It immediately tells you that a Property is a Boolean. You might use it or not, the most important thing is to be consistent about it...
Thomas