Don't you ever get business requirements that touch hundreds of existing use cases? Or business requirements that sudenly require paying atention to concurrency in multiple parts of the code? Or business requirements that introduce processes that produce and process huge amounts of data?

Conflating business and technical requirements just means the business requirements are not understood correctly.

  This dismissal of business requirements as not generating technical problems big enough to require deep work is very interesting.

> If it's your typical web app implementing some business requirements, then there's no deep work required - it's just talking to the requirements source and converting that into code, as per the chosen web framework.

The key phrase is typical web app. The sentence isn't saying that business requirements always generate shallow work. They're saying that working on a typical web app is almost entirely shallow work.

I would caution against saying there is no deep work required in web app implementation, every case is different, every person has a different threshold for what they consider "deep work". I can be knitting and consider it deep work.