Optimizing the usage of malloc and free is no different than optimizing the run time of any algorithm. The only difference is people believe they can just abstract allocation away and rely on somebody else's code to handle it.
My second question is, can you actually avoid relying on somebody else's code when you call malloc? Due to virtual memory being comprised of pages, address randomization, and other things, heap is not a continuous memory space in hardware ready to be used at the moment program runs. So, what is the cost/benefit of "individually called malloc" for each struct, as opposed to pre-allocating some space? I could be totally out of my depth, in which case ignore me ;)
malloc maintains a shared data structure that is used across cpus and must lock for access to that data structure. There are optimizations there being used with some alternative allocators such as per-cpu or per-thread pool but these only reduce the rate of locks taken.
In addition after you have that virtual memory in hand you need to have physical memory behind it which entails a page fault which switches into the kernel to get you a physical page, this happens per-page.
There is also the effect of physical memory layout on performance, if your memory is perfectly contiguous and your data is laid-out properly you can reap benefits from that compared to the quite likely fragmented nature of data in a heap-allocated setting.
This obviously means that the applications needs to manage its memory allocations on its own but when you really care about performance these become important concepts and I too tend to write my libraries for such reuse and avoid memory allocations inside them where possible.
malloc is a general purpose tool and as such needs to cater to many different environments, including multi-threaded programs so it has to lock its access to the shared data structures it holds to main
The problem is that malloc() needs to be generic. It's not about never calling malloc(), but about deciding when it is necessary for your use case vs. specialized solutions tailored to your use.
In many cases you may know that the allocated structure will always be de-allocated at the same time, for example, in which cases pools/arenas can outperform malloc() by a magnitude or more in the right circumstances, and can also use less memory.