As far as I know, no need to make ‘en’ separately now that we have the “best match” feature in 5.0.2. That was done based on that spec text you also mentioned (https://reference.opcfoundation.org/Core/Part4/v105/docs/5.6.3).

The LocalizedText.Builder.setDefaultText(String) uses NO_LOCALE i.e. Locale.ROOT or empty/null String “localeId” (5.x uses empty string, 4.x used both). This is related to another section of the spec (the “invariant locale” part) : https://reference.opcfoundation.org/Core/Part4/v104/docs/5.10.4.1.
NOTE! You do not have to use this. If invariant locale is not set, then the first text you set via the LocalizedText.Builder is the “default value” in the case of no match at all i.e. this relates to the spec text part ” If there still are no matches, then the Server returns the string that it has along with the locale id. ” in the Part4 section 5.6.3.

Since this is so old text, from OPC UA 1.01 i.e. basically 15 years old, and it hasn’t been used in practice, it is possible there is a contradition. So if you ask “why”, then my answer is sort of “I do not know, no-one has used this feature in 15 years” and https://opcfoundation.org/forum/ might be a better place to ask.

Personally I feel the “best match” logic is kinda a bit not intuitive, but that might also be since my knowledge is limited here. For example, if the client asks en-US, but the server has en-GB, there is a danger that the second index is a direct match and would take precedence, when the user might have wanted “any english”. But maybe the country codes matter more in some other languages.

I think I would need clarifications to the “If the DefaultText does not have a locale, how does the OPC UA client understand how the text was translated?”. Like the answer is “it doesn’t”, but it is unclear why that is a problem i.e. what you would want here and why? It is sort of tied to the “this hasn’t been used in practice”. Typically the value would be just shown as-is. If it is an general client like UaExpert or our UA Browser it would in addition show the localeid part, but it would just be an empty string part if is the NO_LOCALE.