If I understood correctly, TheoryBuilding is rather independent of method — TheoryBuilding is what a programmer would ultimately have to do to succeed, regardless of the exact steps they are asked to take. The exact method they follow is irrelevant in comparison.
I'm not sure mainstream still means the same thing he's talking about, but even in your example of "industrial production", I don't think it's that clear that that contradicts him. He seems to be just saying that whatever that means, it's not enough to fully describe software development. But perhaps competent engineers would end up doing so anyway — in fact, if they follow a similar set of ideas that they carry with them from project to project, they would then have a theory of other people's software that they didn't build themselves, just from being in the same environment.
On the other hand, he does directly say that under the TheoryBuildingView, when the theory of a program is lost, from people being replaced too much, it is really lost, and it is very expensive to reconstruct it. So it really depends on the details of how exactly that "component-based production" works out in practice.
[Note: maybe I misunderstood the paper or something, don't trust me.]
I think many IT firms nowadays have exactly this kind of approach: programmer has to deliver code according to specifications created by designers and stakeholders. Nobody cares what programmer knows and what theory programmer is building - the most important thing is to bring hot new features and to do it quickly.
Off course one can argue that "features", "stories" or "backlog" are needed from business point of view. Okay. But how to construct theory if there is no time for thinking?
https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...