As per the features page, Hardened Malloc (and other relevant memory management hardening) are integral, significant components to GrapheneOS's approach of defending itself against unknown vulnerabilities. Hardened Malloc is one of the more important hardening projects the project has done. In addition, the GrapheneOS MTE implementation and support is one of the most important additions added to the OS since the project started ten years ago. GrapheneOS and Vanadium are the first platform and web browser to incorporate MTE in production. It is such a massive improvement that future devices will need to support MTE before they can be considered in-support for GrapheneOS.
Hardening the memory management makes up a very large security benefit as most exploits (including the most severe) done on the upstream are memory exploits like overflows or use-after-free. Hardened Malloc is designed to mitigate attacks like these in particular plus other forms of heap/memory corruption exploitation. By changing the most exploited components either by hardening them or replacing them with a more secure alternative, the OS is less likely to be effected by exploits (known or unknown) that would target the Android platform. This is part of the second objective (the first being attack surface reduction) for the OS' exploit mitigations, where we try preventing an attacker from exploiting vulnerabilities by making such a move unreliable, unlikely, costly and difficult to develop an exploit for.
As you've already read, the OS zeroes (sanitizes) the kernel and slab memory when it is freed. This would protect against use-after-free as there would be no data to use when sanitized. Address space and memory allocation re-use is delayed through the combination of deterministic/randomized quarantines to mitigate use-after-free as well. The sanitization would also protect against uninitialized data usage and keeps sensitive data in memory for a less amount of time (only when it is necessary to be).
Other types of corruption are also covered, I would recommend checking the documentation here: https://grapheneos.org/features#exploit-protection
and the README for hardened_malloc itself for detailed information on it's security properties, it is quite in-depth and it wouldn't do enough justice within a forum reply: https://github.com/GrapheneOS/hardened_malloc#security-properties
Hardware memory tagging is a separate thing from Hardened Malloc, but it is integrated by Hardened Malloc and helps provide a form of memory safety for memory unsafe code (from C and C++) and low-level unsafe code in safe languages like Java and Kotlin. MTE is enabled for all base OS apps and almost all executables with some small exceptions on those that have bugs. You can use hardware memory tagging if you have a Pixel 8 or later.
As for overcoming this hardening, it is still possible for someone to develop an exploit for the OS providing they had the skills and budget, even if it hasn't been known to be done. Although, it would be far more difficult for them to do in comparison to other platforms because of the hardening work done, ESPECIALLY on a platform incorporating MTE like Pixel 8 or later. It would also be far more difficult to upkeep an exploitation kit because these sophisticated threats would have to work faster against our pace of adding new security/privacy features and improvements. Making the exploit is already difficult, but making sure it is persistent or functional across updates is a harder effort, especially when this solution would need to be bespoke and made purposefully to target GrapheneOS.