It's all about index and query alignment.
If you build your own index and ensure related queries are similarly treated then you can use an index with reversed tokens efficiently for the
*@domain.com search and a different index with non-reversed tokens for making a
bill.gates@* search efficient. If you use the wrong query on the wrong index you end up scanning all unique values in the index rather than being able to quickly seek to the relevant parts. There's no safety rails to prevent you picking the wrong field.
That said, if you bothered to create the appropriate index and the searcher picked the right field then it should be quick and there's no need to verify each of the docs that have that term.
With wildcard field it's a more general-purpose index. One index does leading and trailing wildcards (and arbitrarily complex regex) searches. It has ngram index entries for every character position in the string to make it fast. The downside is that matching purely on this ngram index is not sufficient evidence of a match - for each candidate matched doc the engine also needs to verify that the search expression is indeed in that doc by some follow-up testing (this happens automatically behind the scenes). If you have many docs containing the search term we will have to test each of them. Small numbers of matches will be much quicker.
So it depends. It's unlikely to beat a carefully custom-designed combo of index and query but there's more versatility and less need for multiple data structures.