After being given the advice couple years ago, I found it to be applicable to quite a number of scenarios me and my colleagues faced. In my experience its pretty solid!
There is another trick that I use when I don't control the dev team. For example, say the company has outsourced a pricing app to a third party dev shop, in this case any decision I can make that will make the app more "table-y" I make. So instead of defining control flow to determine price for any given object, what I do is I get them to make a "rules engine" that can operate on the major variables that are typically used to make decisions. That way fine tuning changes can be done on our side, and it doesn't rack up billables. I think this is called "table based design" but Googling for it isn't showing anything.
Some easy wins are to default to making something a "many", even if it is only a "one" or a "one or none" because it makes adding a second case much easier. For example, a user should have multiple roles at multiple projects by default, so business users can do fine grain control over permissions.
Another useful trick is to have default behaviour, but introduce a set of tables for custom settings. This makes it easier to make changes because you don't need to run a migration to add a column to a table, you just write a new record to the "user_overrides" table.
But at the very end of the day, taking on technical debt of any kind can be warranted. It all depends on the stakes. If you need to get something done in a week to close a company-saving deal, then fucking do it. Fix it later. The implied interest rate might be 1000%, but if it saves the company it is worth it.