Adding implicit conversions here isn't going to work, as it doesn't make any sense to do so: the types are not equivalent. E.g. an int and a short, you could argue they're the same when you have a number that fits in a short. But a sortclause and a sort expression, you can't argue they're the same thing, sorry.
However it matters of course where you use the sortclauses In queryspec for instance, the OrderBy() method accepts sortclauses, so you don't need a sortexpression, you can just pass the sortclause created by the operator or Ascending()/Descending() queryspec extension methods.
I agree, wrapping a predicate in a relationpredicatebucket or a sortclause in a sortexpression is kind of verbose, though it's the low-level API, and in general one should use one of the other APIs like queryspec to formulate the query. Adding more overloads indeed won't be an option
What you could do is defining 2 extension methods, SortAscending() and SortDescending() which work on an IEntityField2/IEntityFieldCore and create a sortclause and return a SortExpression with that sortclause. Not ideal, but the implicit conversions won't be added, so that's what could help you (or use queryspec queries )