I do agree your first point about keeping things simple. The problem comes when you grow big enough to then need these complicated things, it becomes hard to "turn the ship" re-engineering everything. I could easily argue that laying down the "main" parts of your intra up front, especially on new projects, might be worth it.
It's true that it's more expensive to do the work later, but you also have way more resources later; in my experience the second term increases faster than the first one. Every day you spend wiring up infra is a day you're not iterating on your product, and from the accounts I've seen, most startups fail because they run out of money before they find PMF, not because they later got bogged down refactoring their V1 architecture.
I advise keeping architecture as simple as possible at first by building a monolith (or maybe FaaS if you're really doing throwaway experimentation), and keep refactoring it until your domain knowledge has solidified and it's clear where your service boundaries actually are; it's very unlikely that you'll get the service split correct the first time if you do it too early.
That does require predicting or assuming what the future will look like. If it becomes an unsuitable choice, then you end up with the same problem of turning the ship and the pain that comes with it. Or if you can be obstinate enough, pass the overhead on to others around you which brings its own pain.
