Depends on what you want to work on. But if you’re picking data structures without understanding the implementation details, then you’re not grokking the decision but instead comparing traits you happen to know about and ignoring the ones that aren’t explicitly thought to be called out. Basically the trait everyone things about is O(1) or not. But the design space for data structures is vast and CPUs they run on complex. Heck, sometimes the available abstractions are readily available just because it provides a simple general propose API that we’ve iterated in through trial and error over a long time. That doesn’t mean that design is actually optimal for your problem. Now in many problems you might not care. But there are definitely problems where you do start to care. All your answer is saying “I work at a very high level of abstraction” which is fine for you but there is real value in being able to cut through layers of abstraction (performance, bug hunting etc) and discarding that as trivia is myopic. It may not be valuable to you but it is valuable knowledge I’ve used countless times in my career.

Think about ECS in games - that requires a knowledge of data structure that transcends big-O trait comparison to exploit CPU architecture for drastically better efficiency.

You might ignore memory allocations but the under the hood allocations can be important in some cases to make sure they play friendly. Or understanding cache impact and why using a linked list may not be a great idea. Or when sorting+searching may make more sense than just searching.

The more you know the better able you are to make effective decisions and people who work strictly in abstractions tend to be limited in their ability to solve problems that cross abstractions.