Почему компилятор жалуется, что «не все пути кода возвращают значение», хотя я ясно вижу, что это так?

Существует поддерживаемый сценарий, когда a становится false, когда вы достигаете конца своей функции. Это сценарий, когда вы отлаживаете свой код и используете отладчик для установки a в false.

Правила компилятора C# изначально просты. В языках, из которых заимствует C#, проблема функций, потенциально ничего не возвращающих, была проблемой, которую нельзя было решить с помощью предупреждений компилятора. Было слишком много ложных срабатываний, поэтому предупреждения были изменены, чтобы предупреждать только об очевидных случаях, вводя ложные срабатывания. Правила C# — это компромисс, при котором ложные срабатывания допустимы, если они понятны человеку, знакомому с правилами, а ложноотрицательные значения неприемлемы. Вам гарантируется, что если ваша функция имеет путь кода, который не возвращает значение, компилятор обнаружит это.

Одна часть этих простых правил заключается в том, что значения переменных не учитываются. Даже если a статически гарантировано равно true, компилятор по своей конструкции не может использовать этот факт.

@PetSerAl уже процитировал соответствующую формулировку в спецификации языка C#:

8.1 Конечные точки и доступность

[...]

Чтобы определить, достижим ли конкретный оператор или конечная точка, компилятор выполняет анализ потока в соответствии с правилами достижимости, определенными для каждого оператора. Анализ потока учитывает значения постоянных выражений (§7.19), управляющих поведением операторов, но возможные значения непостоянных выражений не учитываются. Другими словами, для целей анализа потока управления считается, что непостоянное выражение данного типа имеет любое возможное значение этого типа.

Это часть последней опубликованной спецификации языка для C# 5.0. Версия, которую вы используете, C# 6.0 (это то, что предлагает VS2015), еще не имеет опубликованной спецификации, поэтому возможно, что формулировка будет немного отличаться, но, как показал ваш компилятор, фактически то же правило все еще применяется.

Время выполнения и время компиляции

Ваш пример слишком сложен. Это тоже не скомпилируется:

static int Test()
{
    bool f = true;
    if (f)
    {
        return 1;
    }
    else
    {
        //Not all code paths return a value
    }
}

С другой стороны, это будет:

static int Test()
{
    if (true)
    {
        return 1;
    }
    else
    {
        //No error
    }
}

Я предполагаю, что любые механизмы проверки не имеют достаточной логики, чтобы вывести содержимое переменной времени выполнения. Переменные времени компиляции не проблема.

Я думаю, что компилятор выполняет очень простой анализ кода, и поэтому результат должен быть указан явно.

Это может показаться неправильным решением, но при работе со сложным кодом возвращаемое значение может быть неясным. Значит, программист вынужден его вернуть.

Ваш пример можно сократить до минимума следующим образом:

public static Int32 Main(String[] args)
{
    var printUsage = true;
    if (printUsage)
    {
        return 0;
    }

    // return nothing, so compiler is not happy
}

при этом все еще получая ошибку.

ПРИМЕЧАНИЕ. если вы используете Resharper, он выполнит нужный вам анализ и предупредит вас соответствующим образом:

if (printUsage)         // Warning: expression is always true