There are of course performance requirements for almost any project, but whether your service requires 1 ms or 3 ms in production matters a lot less than whether or not your colleagues can actually understand your code.
As a c dev one of the biggest mistakes I see is some optimizing to get better instruction generation but using shifts instead of divides or things of that sort. If you optimizing like that you probably spent more compute time optimizing than your optimization will ever safe. Plus like the complier in C at least handles that for you.
For example, an extra factor of log(n) is hardly ever relevant, constant factors are almost guaranteed to dominate there.
On the flip side, people are also sometimes surprised to see how quickly an n^3 algorithm becomes infeasible even for very modest data sizes.
For improving performance of larger pieces of code often times it's not really important to talk about big O, but much more about how the data is transformed through the system, how lookups are done in memory, how operations are composed together. Then look at what would be possible in an ideal version of the code, and work towards that in steps. This approach can have orders of magnitude improvements, without changing big O.
If you're starting from scratch, this is much easier. Simply never make your code slow :-)
Of course, understanding big O is still very important and being able to apply it to real-world problems instead of just online code puzzles is even more important.
But I think it's importance is a bit exaggerated in the coding community, when there are arguably much more important skills for engineers such as building good relationships with your colleagues, knowing when to cut corners to get work done on a deadline, and knowing how to negotiate salary and promotions.
Most of the interviewers don't even know to solve those leetcode problems in an optimal way with Clojure.
It might vary if the programming language is not functional.