It does not bring much, but still a little. Mainly:

1. We don't have to copy the data multiple times in the JSON document and thus over the network. Might be useful for large text fields. But then using compression might achieve the same performance gain, or more.
2. It makes the schema a bit more sensible for users who need to read from the Elasticsearch cluster from other applications. Think of it as a bit closer to the "Elasticsearch way".

TBH I put this ticket in the beta backlog mainly because we do make use of multi-fields in Search 5 (for faceting) and we have some code and tests that exist only because of that. So in order to restore this code completely, we'll have to have multi-fields in Search 6. Yeah I know... it's a bit backward.

As long as we don't forget about it when we design our APIs in HSEARCH-3444 Open , I'd be fine with pushing it back to a later 6.x or even simply canceling it, but I don't want us to close the door without thinking about it.