The user can still obviously see the sidebar and knows its a sidebar, it just works better with the design.
Limiting information can be harmful in many cases, and make things more difficult rather than simpler. And consistency can similarly limit usability.
What if I want to select one of 10 colors, with limited screen space? Isn't a select with color swatches perfect? Or even better, color swatches with color names beside? Why do you think that should be limited to plaintext only? That's anti-user.
I don't want to have to click each green to see the swatch. Just put them in a list with swatches. That is obviously the easier UX. Nobody has to stop and think about anything.
"I want things to be worse" is not a compelling argument. Letting developers describe the needs of their applications with a consistent grammar is not unnecessary invention, complexity, or friction.
The grammars of a technology, the set of building blocks with which developers are empowered to create, should balance flexibility with expressive intent. CSS <select> strikes this balance nicely. To decry its inclusion says more about the naysayer than the feature.
And it doesn't get the job done. You can't put stuff like SVGs or complex DOM elements in them, which is a valid use case. Most of the time, when people create custom select boxes, they ignore accessibility. This will fix that issue.
What's worse are the custom JS ones that only appear on hover, obscuring the contents partially where they happen to be, and then when you try to drag them and accidentally move the pointer just a tiny bit off their skinny width, they disappear and you end up accidentally activating whatever element happens to be underneath.