The counter-point here is that while you can argue about the name, there is a very real issue that poor architecture will slow progress not because it's "hard"

The counter-point here is that while you can argue about the name, there is a very real issue that poor architecture will slow progress not because it's "hard" to implement features, but because organizationally it becomes impossible to get them merged. We have an endless parade of commentary on HN about what and how much should be in commits and pull requests and what have you, but the thing I've always found credulous about these ideas is how they survive contact with a code base where a "small" feature is going to have a very wide-ranging pattern of changes necessary to support it. It doesn't take much before their are features you functionally can't implement, because there's no possible way to build a neat set of commits for them and get that through reviewers - particularly if there's a lot of activity, because the immediate effect is usually that you'll break a lot of other minor patches with the changes (or they keep breaking you). I'm not sure though that I've seen anyone actually prioritize fixing technical debt in these terms though.