This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.
I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platforms.
What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify.
But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.
I think there is a tradeoff, you can pick some customizable off the shelf software or some low code platform that fits your initial needs, that will give you speed at the risk of not being flexible enough later. Or you fire up your IDE and start from scratch, do everything on your own, that will make you slow, at the very least in the beginning, but you get all the flexibility and also all the opportunities to screw it up.
