Important for what? For interviews? In the real world, inefficient software wins because it appears to do more work. When the slow behemoth has to learn a new trick, you feel like a hero for taming the beast. You get praise when you reduce the runtime of something from five minutes down to four minutes. You don't get time to rewrite the mess so that it would complete in seconds. That would obviously be impossible because we just spent weeks on the one-minute improvement, right? With a bit algorithmic knowledge, this kind of speedup would be possible, but the knowledge is rare.

One could even argue that the algorithm interview trope is harmful because it puts this type of knowledge in the "useless in practice" drawer that will never be opened again.

How important though? Rarely does it come into play from my experience, at least for those who work in predominantly the UI layer on the web. Even at my job at Big Co. as a senior engineer (algorithms/data structures knowledge is necessary to pass the interview process here), it hasn’t manifested in a significant way, at least not compared to other skills such as architecting systems for maintainability, identifying the cause of bugs & fixing them, and collaborating with other engineers to implement something the best way possible.

I'm not saying it's impossible to code without knowing this stuff, just that it gives you an edge as it helps a lot when you have to deal with memory and speed constraints. If you're coding UIs for web apps, you're probably not going to run into issues unless you're dealing with large collection or collections where the record sizes are big. If you're writing backend processes, mobile apps, games, embedded apps, graphics processing apps etc. knowing algorithms and data structures is important.

Would you really want to work with an architect who had no understanding of algorithmic complexity, linked lists or hash tables? An architect needs to know how to design something that will scale to the data involved; I don't see how you can do that if you're ignorant about basic data structures and algorithms.

If a backend process is slow, you buy another server, install Hadoop or something and call the whole mess "big data".

Mobile apps are known for taking ages to load and for taking too much space. They usually block on network requests and are eager to throw information away before blocking on a request to fetch the same information again.

Embedded applications know what hardware they are running on, so they can waste all of the available resources. Extending them later is often very difficult due to that.

In realtime graphics the required knowledge is very specific to realtime graphics. 101 algorithms won't help you at all.

In non-realtime graphics, who cares? Let's spend this quarter's budget on a redesign of the progress bar so that we can have meetings and beautiful powerpoints.