When a design requires something special from inputs, layout designers crouch in the twine and do pretty crazy things, like an image inside the input, but still leave the tag
<input> on the page. However, if suddenly it comes to styles of a drop-down list, the tag
<select> along with a set of
<option> tags go to the dump, and then
A traditional select is awesome, it is opened with "Cmd+down", closed with "Esc", it supports search (just open a select and start typing), and nothing of this, as a rule, cannot be done by all your custom selects. Just because a design developer, working on this component, has not gotten around to that yet.
Of course, there are some successful solutions, for example, custom selects from bootstrap, jQuery, and similar and famous React.js component. But even in these cases the number of leaky abstractions is not zero, but simply less than in other analogs. If you think that you know an example that proves the opposite, where a set of divs behaves exactly the same as an original select and no abstraction leaks, then you should immediately remember about autocomplete of forms in browsers or about long drop-down lists and low browser windows.
visibility: hidden. You could also notice on slow computers that calculation of the select's position were lagged a little behind when scrolling a page. Select calculated its position a bit later than a page itself did that, and moved with a slight delay.
Currently we're working on custom selects.
In that one, which is "multi", I still tried to implement a proper work with a keyboard, but I dumped it when it came to a usual select. If you try to copy the behavior of a native element, you can waste a week, while nobody ever estimates a div with a text and another div with a drop-down list at a whole week.
And you should not forget about custom selects on mobile devices. This is a separate pain for the user, and native selects are completely different anything else, take, at least, those iOS "drums". And, surely, the user won't be delighted with custom designer's garbage.
Another interesting idea is of the evolution of native controls. Take, for example, the scrollbars. In the past, we had bags and bags of libraries implementing custom scrollbars. And if at that time a designer could not resist the temptation to add a little beauty to his creation, now his scroll, no matter how cool it was before, will look pretty dull against the backdrop of neat, sometimes even self-removing in passive state native scrolls. Of course, no design lives for so long, but it's great to always keep in mind the possibility of browser evolution when working on a design.