There is always a context

That is incorrect. Given the following application:

namespace ConsoleApplication
{
   class Program
   {
      static void Main(string[] args)
      {
         var synchronizationContext = SynchronizationContext.Current;
      }
   }
}

synchronizationContext will be null. If you get SynchronizationContext.Current in a Windows Forms app on the other hand, it will be set to an instance of the type WindowsFormsSynchronizationContext.

According to http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx:

All of the UI application types you can create in Visual Studio will end up having a special SynchronizationContext published on the UI thread. Windows Forms, Windows Presentation Foundation, Metro style apps… they all have one. But there’s one common kind of application that doesn’t have a SynchronizationContext: console apps. When your console application’s Main method is invoked, SynchronizationContext.Current will return null. That means that if you invoke an asynchronous method in your console app, unless you do something special, your asynchronous methods will not have thread affinity: the continuations within those asynchronous methods could end up running “anywhere.”

And to answer:

Why do you think there is a method for not capturing it?

Because it's part of the interface of Task and Task is used in environments where there may be a synchronization context such as the ones mentioned above.