It depends on the targeted SQL engine. Mainly because each engine has different approaches when it comes to scanning full tables, and using indexes.
If we talk about a non-indexed table or a hint that forces a full-table scan, there is not really a difference between the two examples, because at a lower level they're both filters, and will be treated in the same way.
On the other hand, when indexes are involved:
In SQL Server, you have basically two types of index operations: Scan and Seek. Their performance depends mainly on the percent of rows returned from the candidates (or total). As long as in the examples you provided you're using the same values/bounds, the operation is the same. It is either a Scan, or a Seek, filtered by your values.
In Oracle, there are more types of index scans. They're chosen by the optimizer depending on the how the indexes are built on the table. For instance when using bounded intervals (<= and =>) the optimizer will most likely chose a range scan; in the other example, it will perform either a skip scan, full scan, or even an unique scan. Their performance is subjected to the whole structure of the table, and again, on the percent of numbers returned.
In conclusion, neither of versions is universally better - it depends on your scenario. Even more, if you use the proper hints, you can end up having the same execution plans for both of them.