The short answer is that range comparisons on strings in Azure Search are not officially supported, so you should use Edm.DateTimeOffset to hold date/time information.
The longer answer is that range comparisons on strings will work, but only outside the context of a lambda (any or all). This was kind of an accidental feature that we decided not to remove in case people were using it, but we also decided not to advertise since the fact that it only works outside of lambdas can be confusing.
If you'd like Azure Search to support range comparisons on strings across the $filter syntax, please add a suggestion on User Voice.
Assuming that you're fine with the functional limitations of range comparisons, there is still the performance question to answer. This is not something we've benchmarked, but we can speculate a bit.
Under the hood, Edm.DateTimeOffset is stored in the inverted index as a long number of milliseconds since the epoch. In Lucene terms, they are queried using NumericRangeQuery instead of TermRangeQuery. Numeric fields are indexed using tries, which speeds up query performance versus the equivalent term range query. The Lucene documentation is a good starting point to understand how this works if you're interested in going in depth.
And is there any azure search feature that is data-type specific to DateTimeOffset?
Yes. The freshness scoring function requires a DateTimeOffset field, and there are certain options for interval faceting (day, month, year, etc.) that only apply to DateTimeOffset fields.
