I think it's a reference to the book "How buildings learn". I haven't read the whole book but as far as I have read it goes like this: people try to guess what the good building supposed to be and build it but later they have a change of heart or either some other people move to that building and have completely different outlooks of what their home should be like. Author argues there is levels to buildings and we should build bottom levels in a way that won't hinder later changes to upper layers because the bottom levels are unchangeable and you would be better off destroying and rebuilding it if you want to change those bottom layers. Software seems to be related in a sense that the bottom layers of your app should be developed in a way that won't be in the way of developing new features because if that happens you would need to rewrite from ground up.

I think it’s because this is an analogy that’s used explicitly and implicitly by non technical people. So I use the analogy in order to refute it.

What I say is, software is almost nothing like a building. Software doesn’t get built once; it grows over time. Even if you don’t change the functionality, external factors like security updates and changes in fashion force you to continually update it over time. A much better analogy, if you need one, is a garden or park.

It's mainly to help software 'architects' sleep at night

I compare it to buildings a lot, especially when explaining things to non-technical stakeholders.