I've not found it that important except to communicate ideas, and I work in performance-critical fields (raytracing, image and mesh processing, particle systems, physics engines, etc) and have had to devise a lot of proprietary algorithms and data structures when working in R&D. In these areas, often a handful of very efficient data structures and algorithms can yield whole new cutting-edge products while yesterday's algorithms make existing products obsolete, so there's always a pursuit of doing things more efficiently. As a caveat though, I've never published any papers on the algorithms I devised. They were all proprietary. If I did, I'd need the aid of a mathematician to formulate proofs and so forth.
Yet in my opinion the amount of computational work per iteration is often of more immediate interest than the scalability of the algorithm unless the algorithm scales really poorly. If someone comes up with a cutting-edge technique for raytracing, I'm more interested in the computational techniques like how they represent and access data than algorithmic complexity because reasonable scalability is already a given in this competitive and innovative scenario. You can't be competitive coming up with algorithms that don't scale.
Of course if you're comparing quadratic complexity to linearithmic, that's a huge difference. But most people in my field are competent enough to avoid applying a quadratic complexity algorithm on an epic input. So scalability is often deeply implied, and the more meaningful and interesting questions become like, "Did you use GPGPU? SIMD? Does it run in parallel? How did you represent the data? Did you reorganize it for cache-friendly access patterns? How much memory does it take? Can it robustly handle this case? Are you deferring certain processing or doing it all in one go?"
Even a linearithmic algorithm can outperform a linear-time algorithm if the former accesses memory in a more optimal pattern, e.g., or is better suited for multithreading and/or SIMD. Sometimes even a linear algorithm can outperform a logarithmic algorithm for these reasons, and naturally linear-time algorithms outperform logarithmic ones for teeny inputs.
So to me what matters more are what some people might call "micro-optimizations", like data representations (memory layouts, access patterns with hot/cold field splitting, etc), multithreading, SIMD, and occasionally GPGPU. In a field where everyone is already competent enough to use decent to cutting-edge algorithms for everything with new papers being published all the time, your competitive edge in beating the algorithmic wizards doesn't come from improvements in algorithmic complexity so much as more direct computational efficiency.
My field is dominated by brilliant mathematicians but not always ones who know the computational cost of what they're doing or a lot of the lower-level tricks to speed up code. That's usually my edge over them in devising faster and tighter algorithms and data structures in spite of mine being a lot less sophisticated. I'm playing to what the hardware likes, towards bits and bytes and making each iteration of work much cheaper even if I'm doing a few more iterations of work than the really sophisticated algorithm -- the work in my case is drastically cheaper. The code I write also tends to be a lot simpler. If people think micro-optimized versions of straightforward algorithms and data structures are hard to understand and maintain, try understanding and maintaining a collection of exotic mesh-related algorithms and data structures never seen before in the industry with 20-page papers describing their steps mathematically.
As a basic example, I came up with a simple grid structure which ended up outperforming a KD-tree at our company for collision detection and redundant point removal. My stupid crude grid was so much less sophisticated algorithmically and I'm much dumber mathematically and algorithmically than the guy who implemented the KD-tree with his novel way of finding the median point, but I just tuned my grid's memory usage and access patterns and that was enough to outperform something much more sophisticated.
Another edge I have that allows me to survive in a field dominated by people much smarter than me is just really understanding how the user works, since I use the software I develop the same way. That gives me ideas for algorithms that really align very immediately with user interests. As a basic example there, most people try to accelerate things like collision detection using spatial indexing. I made a simple career-shaping observation almost a couple of decades ago for organic models that, for example, if a character places his hands on his face, a spatial indexing structure would want to have to split nodes and do expensive updates if the character then took his hand off of his face. If, instead, you partition based on connectivity data rather than vertex positions, you can end up with a stable hierarchical structure that updates very rapidly and never needs to split or rebalance the tree (only has to update bounding boxes every frame of animation)... things like this -- algorithms a kid with no heavy mathematical background could come up with if they just understood the basic concept, but ones that eluded the mathematicians since they weren't thinking of things in a way so close to how the users worked and were thinking too much just about properties of geometry and not how geometry was commonly used. I get along well enough by leaning more on general computational knowledge and user-end knowledge than algorithmic wizardry. So anyway, I haven't really found it that important to focus on algorithmic complexity.