In my field (VFX, which covers things like path tracing, computer animation, particle simulation, fluid dynamics, image processing, etc), algorithmic complexity is fundamental. There's no way anything operating in worse than linearithmic time can hope to complete in any reasonable time on inputs that commonly reach millions of vertices, polygons, voxels, particles, texels, especially when many of these things need to complete many times a second to provide real-time, interactive feedback.
With that said, there's not that strong of an emphasis on algorithmic complexity in discussion typically among colleagues, perhaps because it's somewhat taken for granted and rather "rudimentary". It's generally assumed if you're writing a path tracer that it's going to operate in logarithmic time or better, and that data structures like bounding volume hierarchies are familiar and relatively trivial to implement for the reader. I even had a skilled colleague who kept saying that multithreading and SIMD are more important than algorithms, and I don't think he meant that in the sense that you could expect to get much out of parallelizing a bubble sort. I think he said that because he took it for granted that we'd apply sensible algorithms, and the rest of the challenge is often parallelization and choosing and adapting algorithms and designing the data representation to operate in parallel.
Often a lot of the focus these days is on taking many of these familiar algorithms and making them better exploit the underlying characteristics of the hardware like the CPU cache, SIMD registers and instructions, GPUs, and multiple cores. For example, Intel came up with a novel way of taking the familiar old BVH and coming up with the concept of "ray packets", basically testing multiple coherent rays at a single time with a recursive sort of tree traversal (which might sound like it'd come with its share of complexity and overhead, except it's more than made up by the fact that those rays can now be tested simultaneously for ray/AABB and ray/triangle intersections through SIMD instructions and registers). Other cutting-edge path tracers have managed to implement such spatial indices and actually perform the ray intersections directly on GPU.
Similar thing with like catmull-clark subdivision, which is very rudimentary stuff in computer graphics. But nowadays what's competitive and hot and super efficient are GPU implementations which approximate CC subdivision using Gregory Patches, as popularized by Charles Loop and later adopted by Pixar. The more straightforward CPU implementation is now rather obsolete, not necessarily because it was superseded in terms of algorithmic complexity, but because it was superseded by something that plays well with the GPU.
And that's usually a lot of the challenge these days is not coming up with the best algorithm in a way that's relatively independent of the underlying characteristics of the hardware. I actually got my foot in the industry by coming up with a novel acceleration structure that significantly sped up collision detection for animating characters and other soft bodies in the 90s using a hierarchical segmentation approach as opposed to a spatial index, which got me a lot of job offers, but these days it's not so impressive anymore since I published it long before we had such impressive CPU caches and multiple cores and programmable GPUs and what not, and nowadays I use a completely different approach as a result of the significant changes to the underlying hardware. So the focus has actually shifted more towards what might be in the realm of "micro-optimizations" in my case over novel algorithmic concepts because now we've got multiple cores, AVX registers, GPU shaders, etc. It's a different ball game to me now where I can't just hope to compete by coming up with a cool algorithm unless it really plays well with the peculiar nature of today's hardware which especially requires a lot of attention and care these days to fully exploit.