try/finally vs. local temp variable

There's a very big difference between the two options you have presented and they don't fall into the categories of readability, elegance etc. It falls into realm of correctness.

Code in a finally block always executes even if an exception is thrown in the try block. So, if it's critical to the program's execution that RegisteredForMeasurement needs to be assigned to false, even in the event of an exception, then you would you would do that in the finally block. If it's critical that it isn't assigned in the event of an exception, then you would code accordingly.

When we talk about readability or elegance, we're talking about code that does exactly the same thing, but designed in a way that is easier to comprehend. In this case, it doesn't apply because you're talking about two pieces of code that perform very different things in different scenarios.

"Is version 2 faster, as it does not need a temporary local variable or does it end up to be about the same after JIT-optimizations?"

On the contrary. Even if using try..finally has litte overhead, a local variable is very, very cheap.

The extra time for allocating a local variable is actually zero. The space for the local variable is allocated by moving the stack pointer, and that is done anyway when the stack frame is created for the method, so the allocation is completely free.

Storing the value in the variable is cheaper than the extra work needed to set up the exception handling.

Just for fun I benchmarked the two methods, and using try..finally takes about 50% longer in x64 mode and about 200% longer in x86 mode. However, to get some perspective consider that the time difference is about a nanosecond.

Using try/finally is perfectly alright to use for programming logic. The reason you shouldn't use try/catch for logic is because it breaks up program flow, and can be time consuming(especially in debug mode). However, using the finally portion of a try just to return a value later is ayokay. I would caution you though to keep your code readable, and readily understandable, and a try-finally may hinder you in that endeavor.

Though to make your own educated decision I also want to show you the difference it makes in the IL (which C# is compiled down to). For the purposes of this example I assumed that whatever was being returned by EngineCommands.CommandReset() was just an object. For each of these I've showed the C# then its compiled IL.

var result = EngineCommands.CommandReset();
RegisteredForMeasurement = false;
return result;

Results in the following:

.maxstack 1
.locals init ( [0] object result )

IL_0000: call object EngineCommands::CommandReset()
IL_0005: stloc.0
IL_0006: ldc.i4.0
IL_0007: call void Program::set_RegisteredForMeasurement(bool)
IL_000c: ldloc.0
IL_000d: ret

try { return EngineCommands.CommandReset(); }
finally { RegisteredForMeasurement = false; }

Results in the following:

.maxstack 1
.locals init ( [0] object CS$1$0000 )

.try
{
    IL_0000: call object EngineCommands::CommandReset()
    IL_0005: stloc.0
    IL_0006: leave.s IL_000f
}
finally
{
    IL_0008: ldc.i4.0
    IL_0009: call void Program::set_RegisteredForMeasurement(bool)
    IL_000e: endfinally
}

IL_000f: ldloc.0
IL_0010: ret