Because it can be changed using Reflection:

using System;
using System.Reflection;

public class Program
{
    public static void Main()
    {
        var t = new Test();
        var field = typeof(Test).GetField("myVar", BindingFlags.Instance | BindingFlags.Public);

        Console.WriteLine(t.myVar); // prints True

        field.SetValue(t, false);
        Console.WriteLine(t.myVar); // prints False

        // Trying to use t.myVar = false or true; <-- does not compile
    }
}

public class Test
{
    public readonly bool myVar = true;
}

Working Fiddle: https://dotnetfiddle.net/W9UO3m

Note there is no way in which the compile time code optimizer can predict or detect with absolute certainty whether or not such reflection code exists, and if it exists, if it will run or not.

Your proposed optimization really is a combination of two individual simpler transformations. First is pulling the member access outside the loop. From

for(int i = 0; i != 10; i++)
{
    var localVar = this.memberVar;
    if(localVar)
        DoStuff();
    else
        DoOtherStuff();
}

to

var localVar = this.memberVar;
for(int i = 0; i != 10; i++)
{
    if(localVar)
        DoStuff();
    else
        DoOtherStuff();
}

The second is interchanging the loop condition with the if condition. From

var localVar = this.memberVar;
for(int i = 0; i != 10; i++)
{
    if(localVar)
        DoStuff();
    else
        DoOtherStuff();
}

to

var localVar = this.memberVar;
if (localVar) {
    for(int i = 0; i != 10; i++)
        DoStuff();
}
else {
    for(int i = 0; i != 10; i++)
        DoOtherStuff();
}

The first one is influenced by readonly. To do it, the compiler has to prove that memberVar cannot change inside the loop, and readonly guarantees this¹ -- even though this loop could be called inside a constructor, and the value of memberVar could be changed in the constructor after the loop ends, it cannot be changed in the loop body -- DoStuff() is not a constructor of the current object, neither is DoOtherStuff(). Reflection does not count, while it may be possible to use Reflection to break invariants, it isn't permitted to do so. Threads do count, see footnote.

The second is a simple transformation but a more difficult decision for the compiler to make, because it's difficult to predict whether it will actually improve performance. Naturally you can look at it separately by doing the first transformation on the code yourself, and seeing what code is generated.

Perhaps a more important consideration is that in .NET, the optimization pass takes place in between MSIL and machine code, not during compilation of C# to IL. So you cannot see what optimizations are being done by looking at the MSIL!

¹ Or does it? The .NET memory model is considerably more forgiving than e.g. the C++ model where any data race leads very quickly to undefined behavior unless the object is defined volatile/atomic. What if this loop runs in a worker thread spawned from the object constructor, and after spawning the thread, the constructor goes on (which I'll call the "second half") to change the readonly member? Does the memory model require that change to be seen by the worker thread? What if DoStuff() and the second half of the constructor force memory fences, for example access other members which are volatile, or take a lock? So readonly would only allow the optimization in a single-threaded environment.

A readonly field can be initialized to different values at different points in the code (multiple constructors). It can't be optimized out because multiple constructors allow for multiple values of the field in question. Now, if you only had one constructor, with no relevant branching, and therefore only one possible value, ever, for that field, I'd expect more from the optimizer. However, that sort of analysis is one reason that C++ takes much longer to compile than C#, and these sorts of tasks aren't typically delegated to the runtime.

For a clearer explanation:

Note

The readonly keyword is different from the const keyword. A const field can only be initialized at the declaration of the field. A readonly field can be assigned multiple times in the field declaration and in any constructor. Therefore, readonly fields can have different values depending on the constructor used. Also, while a const field is a compile-time constant, the readonly field can be used for run-time constants as in the following example:

See https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly

For your specific case, I'd suggest using const instead of readonly, though admittedly I haven't looked for differences in the generated IL.

Honestly, I'm wondering if it really makes a difference. Any CPU that performs branch prediction and has a halfway-decent cache will likely yield the same performance in either case. (Note that I haven't tested that; it's just a suspicion.)