Which thread a task runs on is an implementation detail. One you could only ever nail down if you use a task scheduler that knows how to run code on a specific thread. Like TaskScheduler.FromCurrentSynchronizationContext(). Which will never work in a console mode app since it doesn't have one.
So it is up to the Task class implementation to figure out what thread to use. And it will look for an opportunity to not require a thread context switch, those are expensive. If it has a choice between starting a threadpool thread to execute code and waiting for it to complete vs executing the code directly then it always will pick the last choice, it is superior.
It found one in your code, you called the Abort() method on your main thread. Which, through lots of layers in the Task class plumbing (look at the Call Stack window), figured out how to call the finally block on the same thread. This is a Good Thing of course. And one you should expect, your thread doesn't have anything else to do so it might as well be used to execute task code.
Compare to using CancelAfter(), now your thread is not suitable to execute the finally block and you'll see the finally block execute on a TP thread.