For me, it's a matter of avoiding premature optimization. When I end up dealing with needing to optimize my code, very rarely is the data structure the primary pain point. Just because something is "easy to use" doesn't necessarily mean that the faster alternative is worth the opportunity costs.
I prefer the Donald Knuth quote:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
As far as I've seen in my own code, and those of my coworkers, we use all kinds of data structures when they're appropriate to a requirement and its constraints.
Are you suggesting that some people stubbornly don't use data structures that they're familiar with, even when they're important to speed/performance? I can't say I really see that happen very often. It's usually either that the engineer didn't happen to know the optimal solution, or (as was mentioned elsewhere) the optimal solution wasn't necessarily worth pursuing.
This, of course, is taking into consideration that the problem is non-trivial, and it improves the speed/performance.
I also use alot of javascript, and there it is natural to use sparse arrays, which wind up being hashtables. iterating over these can be an issue though, so i have found that combining the hashtable with a linked list results in the best performance.