Removing a Detach method from the (DbContext) API has some logic because Detach doesn't operate on an object graph but it only detaches the single object that you pass into the method. This is different to all other methods that change the object state:
Attach attaches the supplied object including all related objects in the object graph of navigation properties
Add adds the supplied object including all related objects to the context
Remove deletes the supplied object including the related objects that have been configured with cascading delete
On the other hand setting the state manually to Modified, Added or Deleted always only acts on the supplied object, not on the related objects. This is also the case for calling the Detach method of ObjectContext. It is more consequent to detach an object only via setting the state to Detached to be in line with the behaviour of other state changes because like setting any other state it only influences the supplied object without related objects.
DbContext is - among other features - intended to make working with Entity Framework easier. The old Detach method was more confusing and its behaviour is not like many developers expect. (Here and here are two references about this confusion and the complexities involved in detaching an object.) In my opinion it wasn't the wrong step to remove it from the DbContext API.
Well, you can always write you own extension method like you did or access the underlying ObjectContext via the adapter if you really want to have a Detach method.