Hello @cvinod,
The reasoning for this much advised slack-space is to ensure that there is enough space to rebuild vSAN Objects in the event of a failure/loss of access to some data-components or to reconfigure the data (e.g. applying a new Storage Policy).
Obviously this depends on the configuration - for instance a 4-node cluster with RAID5 Objects won't be able to rebuild data in the event of 1 node permanently failing (need 4 available FDs), but you still need temporary available space for reconfiguring these (e.g. switching to RAID1 or increasing Stripe Width). The larger the cluster the lower the proportion of capacity that is required to be able to rebuild a failed node, so technically from a recovery perspective less than 30% is really required if there are a larger number of nodes in the cluster, though if going lower than ~30-25% pay mind to how changes to Storage Policies are made (e.g. don't try to change all Objects from R5 to R1 at once).
With regard to "slack" at the SSD-level, this is used for reliability to replace dead/dying blocks and is pre-configured by manufacturer (and/or by user) and is not tunable from vSAN (if that is what you were referring to).
Bob