Hello,
To answer the general question: you can customize how the clearing of buffers is done by setting MBEDTLS_PLATFORM_ZEROIZE_ALT to a function of your choice. Technically, you can make it a no-op.
Now, whether you _should_ make it a no-op is a different matter. Zeroization is a second line of defense: if there are no bugs anywhere, zeroization is useless, since you can't observe its results. So it's a matter of how much you trust all the code that's running in the same memory space: Mbed TLS, the platform's standard library, other libraries, your application, the operating system, the hardware... Experience shows that as much as we try, bugs (including unintended indirect data leaks via side channels) do happen. Most security certifications require clearing secrets in some form.
The one case where I would personally suggest making mbedtls_platform_zeroize a no-op is if you're using the crypto part of the library in a crypto service running in its dedicated memory space, with a platform that takes care of zeroization. Specifically, if the platform's free() function zeroizes memory (takes care of heap data) and the crypto service wipes its stack (in some platform-specific way) after responding to each request. Under these assumptions, the only places where mbedtls_platform_zeroize() has an effect is if the memory is reused by crypto code, and in those few cases I'm reasonably confident that secrets won't leak. I'm less confident with TLS code (which has far more complex dynamic memory management and variable-size buffers), so keep zeroization active there.
(And yes, it would be nice if Mbed TLS had a more flexible interface, so that you could for example make mbedtls_platform_zeroize() a no-op only when it's called before mbedtls_free() if your platform's free() zeroizes. Unfortunately, implementing that would be a huge task.)
Also, I don't know if it would make much of a difference in practice, but if your platform has a zeroization function in its standard library (e.g. memset_s() or explicit_bzero()), it might allow the compiler to optimize slightly better (for example, it might figure out that zeroizing twice is redundant, which it can't with our portable implementation because it works very hard to hide what it's doing so that the compiler doesn't completely optimize it out).
Best regards,