I'm not sure the use case of validate-multicast is well understood here. It's a low-level network debugging tool that's meant to be run iteratively while trying to get multicast working between nodes. Even if a remote version of the command ever exists, just running it one time in the admin console won't give much more information than what you get from get-health. And you won't be able to fix the problems through the admin console (e.g., misconfigured router or machines on different subnets). We even state that the app servers should be shut down when trying to fix this problem.
If you can show the cluster health in admin console, then I think you should. Don't withhold some useful info just because it's not all the info. IMO, if the instances are running (list-instances shows them up), but they're not seeing each other (get-health shows them down), then the cluster is broken. We tell users to manually run get-health, but that doesn't mean they do, and a single instance that's running but is isolated from the group is a bad problem waiting to happen – no one may notice till it fails and sessions are not replicated anywhere.
All you'd have to do is add a sentence on the page that if the output from the two commands differs, there is a problem in the cluster and they need to debug it.