I use CS theory all the time in my professional career. Automata, was the most useful class I took (the 2nd most useful was Programming Language Concepts).
I don't dispute at all that theoretical CS is practically useful, I love it myself and think it offers amazing tools for thought. But my hunch is (and I'm emphasizing that I'm speculating here) that only people who like the material end up retaining enough to see the applications. I feel like some of my fellow students, including ones that I felt were smart (but who were application-oriented learners who have trouble focusing if they didn't see applications right away), had to drag themselves through the theoretical material to barely pass and then promptly forget about it. I imagine their perspective is:
1. They have to work through material that does not particularly interest them and is quite hard, but employers insist that they must master this stuff if they want a good position.
2. In their work environment, no one ever asks them to actually use theoretical CS concepts, and they don't spontaneously see applications themselves.
3. Therefore, they feel academia is out of touch and teaching irrelevant material that has no practical application. With my earlier comment I wanted to point out that I don't believe academia is to blame for their suffering.
That's the thing, it is useful, so I don't blame companies for wanting people who know CS theory.
And when I hire people, even though I hate doing adversarial whiteboard coding, I will probe to find out if people understand a bit of theory.
You can get a lot of work done without theoretical knowledge, (but the end result is often not as good, and it usually takes longer). Combine that with the fact that CS theory is hard, and you get a lot of people complaining about how theoretical CS is useless outside of academia.
It's basically an extension of "no one needs to know math beyond arithmetic in the real world".
What's amazing to me is how uncommon state machines are in software, comparatively. In ASIC and FPGA design, it's so fundamental and ubiquitous. At least with synchronous designs.
I pushed for using state machines and more formal methods in the rewrite of a system that I and a number of other devs were hired for. The idea was turned down in favor of lots of ad hoc state and string constants, even though the system has a limited and distinct set of states on the main domain objects. People don't do it because people don't do it, and they're afraid others aren't going to understand it.
The vast majority of companies essentially code and design to the lowest common denominator so that their devs are fungible cogs.
The problem is that it's extremely easy to violate the boundaries of state machines. For example there's some small edge case, that would normally require you to completely re-create the state machine, but people bypass that by just escaping the state machine. In ASIC/FPGA, it's actually relatively hard to escape the state machine because escaping the state machine causes explosions in timing required and causes race conditions.
Code doesn't have fixed timing requirements, most of the time.
For embedded systems and game development I definitely understand automata applications (from experience) but web development has me curious. Are you writing transpilers or perhaps something else (I also try to avoid web dev, so there's that).
Mostly for user interfaces and modeling business processes. But I’ve also done some work on a super simple language for some of our non technical people to use for data transformation, and a templating system for form generation.
Ecommerce order/payment/shipping status is a good example. Anything that has a well defined state that can be changed by events is well-modeled as a state machine of some kind. Also anything that has to progress through certain steps and might be interrupted or have exception cases, and you want to proceed/retry idempotently.
Personally I have also found basic graph theory to be immensely useful for representing and reasoning about things.
