Почему полезно обращаться к статическим членам «через» унаследованные типы?

Я рад, что C # не позволяет вам обращаться к статическим членам, как если бы они были членами экземпляра. Это позволяет избежать распространенной ошибки в Java:

Thread t = new Thread(..);
t.sleep(..); //Probably doesn't do what the programmer intended.

С другой стороны, позволяет получать доступ к статическим членам «сквозных» производных типов. Кроме операторов (где это избавляет вас от написания приведений), я не могу придумать ни одного случая, когда это действительно полезно. Фактически, он активно поощряет такие ошибки, как:

// Nasty surprises ahead - won't throw; does something unintended:
// Creates a HttpWebRequest instead.
var ftpRequest = FtpWebRequest.Create(@"http://www.stackoverflow.com");

// Something seriously wrong here.
var areRefEqual = Dictionary<string, int>.ReferenceEquals(dict1, dict2);

Я лично продолжаю совершать похожие ошибки снова и снова, когда ищу свой путь через незнакомые API (я помню, как начинал с деревьев выражений; я нажал BinaryExpression. в редакторе и задавался вопросом, почему IntelliSense предлагает мне MakeUnary в качестве опции).

По моему (близорукому) мнению, эта функция:

1. Не снижает многословность; программист должен так или иначе указать имя типа (исключая операторы и случаи, когда осуществляется доступ к унаследованным статическим членам текущего типа).
2. Поощряет ошибки / вводящий в заблуждение код, подобный приведенному выше.
3. Может подсказывать программисту, что статические методы в C # демонстрируют своего рода «полиморфизм», когда это не так.
4. (Незначительное) Представляет «тихие», возможно, непреднамеренные возможности повторного связывания при перекомпиляции.

(ИМО, операторы - это особый случай, требующий отдельного обсуждения.)

Учитывая, что C # обычно является «ловушкой успеха» язык, почему эта функция существует? Я не вижу его преимуществ (кроме «возможности обнаружения», которая всегда может быть решена в среде IDE), но я вижу множество проблем.