Those are fair tradeoffs and I think they’re reasonable. My view is that it’s most easiest to i18n at the start of the project. If not, it gets progressively harder. But once i18n is done, it’s pretty straightforward to follow the established patterns for dealing with user-facing strings, and localization mostly comes for cheap afterward (to the developer at least - they just need to maintain the translation pipeline and ensure enough context is provided for each string). At that point, you just need to rely on the community to translate strings, if they care about wanting the client to be in their language. 

 It’s better to translate the UI of a software when the feature design is stable. Otherwise every time you change the menu, you have to change 10 translations.

English is the most widely used language. If we can’t even capture a large number of English users, we fail. 

 Sure, but also internationalizing your UI so that localization can happen at anytime is even better. We can capture English speaking users and still cater to non-English speakers. I don’t think any of this is mutually exclusive.