There is quite a lot to this question, I prefer to develop in en_US (and leave that language in there)* name all the entities in en_US as well.
*Mendix should offer the option to disable a language to users (e.g. en_US) but still have that language in Studio for development and consistency. If you delete a language it will delete every translation in that language, while Mendix already supports some sort of disabled languages: import a marketplace module with a language not in your project the additional language (e.g. es_US or es_MX) is still imported and translations exists.
Another thing to consider is the calculations based upon the locale setting (if only Mendix had the option to set a default locale...), i.e. date functions.
For example: if your language is set to en_US and you’ll want to retrieve the week number of a given date (i.e. 22-jun-2022), using formatDateTime, it will give you a week number based upon the en_US locale settings (so you’ll get week 26). If your language is set to nl_NL, it will give you the week number based upon the nl_NL locale settings, which will return week 25 for that same date. So the language setting has additional side effects which are not always evident.
The main problem I see with keeping the language on English but writing content in Dutch, is that you will have a problem if you decide to add English as a second language later on.
Because of that I would always recommend to set the language to Dutch if you are writing content in Dutch. For projects that are already going for sometime I guess you will have to decide if there is a chance that you will add a second language and if it is still doable to actually add Dutch as a language and fill in all the captions. Most of the time it is probably not worth doing that work, unless you might add a second language.
Comments, technical specifications, protocols and documentation are probably better readable and maintainable when written in a native language.
But Mendix is a low-code platform and has a lot less of these challenges. When working with teams from other countries, the blocks and their code within can be hard to read in a native language.