100% agreed, as I mentioned in house knowledge (and engineering size) matters when deciding this. In your example, if you only have recent graduates in your team you have a whole lot of different problems :D In a more common setup (some seniors, some juniors) given they will have to learn something on the road anyway, wouldn't you want to, for example, use managed services instead of "boring" services? Use svelte instead of angular? use flask instead of django? or fastify instead of express? And if you go boring because there's more literature on them, you will soon find out that most of it is confusing as it spans over the years (have you ever used springboot? so many different ways of doing things that evolved in time...) and in the beginning you'll end up using the - by the book- approach which does bring some complex problems (try refactoring the auth module out of an app).

In the end what you are doing is moving the problem of figuring things out later in the future, when things are much more complex and refactoring is much more costly.

But I agree with you in the end it depends on the org, which is why you should not choose boring tech by default, and not choose cool tech by default either and think more about what would really give you speed of execution and maintainability in an always changing business domain AND keep things small enough that can be refactored out in an as-easy-as-possible way.

ps of course this is after like the first year of your startup, there's no point of doing any of this, or even choosing any technology if your company dies in 3 months.

pps i still don't understand why early stage startups don't do everything in javascript (FE+BE) so the same engineers can contribute to both part of the stack and then decide what to change depending on the business needs