I'm not sure about the advice you heard, I hear 3 master eligible nodes as a recommendation most of the time. And that's what I use in my clusters, ranging from 6 to 20 data nodes.
The point about not getting a split brain is that you want to configure your master eligible nodes in such a manner that if there is a network outage they don't form two or more separate clusters. You prevent this by requiring a minimum number of master eligible nodes to be available for a master to be elected.
I'm still using ES6 and I know there are changes to how this is configured in ES7+, but the effect must still be the same - that you require at least half + 1 of the master eligible nodes to be available for a new master to be elected and a cluster to form.
Let's say I start out with 5 master eligible nodes in my cluster, then I must set the minimum to 3. Then, if I get a network outage some of the data and master eligible nodes will still be in connection with the elected master. If there are at least 3 master eligible nodes in this part of the cluster, it will still work. And because there are at least 3 in this cluster, the remaining nodes that are not in contact will only have at most 2 master eligible nodes on their side of the network break. And that is 1 too few to elect a new master. Hence they can't form a cluster and will not create a split brain problem. And, vice versa, if the current master only sees one other master eligible node, it is below the minimum and will shutdown itself and this part of the cluster - in case the nodes that it no longer can communicate with has formed a new cluster (since they may have the remaining three master eligible nodes).
I hope that answered your question.