Mhm, while these are interesting options for containers like AudioBuffer, Strings or all the Array classes, I’m not sure if this would be such a trivial solution to this problem, at least not from the viewpoint of every JUCE user. Not all of them are pro level C++ programers, if you come from a more DSP background reading something like std::pmr::polymorphic_allocator could maybe not seem like a trivial soultion to your problem 
What I think of would be something like adding a constructor like
IIR::Coefficients<NumericType>::Coefficients (int numCoefficient)
{
coefficients.ensureStorageAllocated (numCoefficients);
for (int i = 0; i < numCoefficients; ++i)
coefficients.add (NumericType());
}
To create a pre-alloated coefficient array.
Then add a member functions like
void IIR::Coefficients<NumericType>::setCoefficient NumericType b0, NumericType b1,
NumericType a0, NumericType a1)
{
// like the corresponding constructor
}
void IIR::Coefficients<NumericType>::setCoefficient NumericType b0, NumericType b1, NumericType b2,
NumericType a0, NumericType a1, NumericType a2)
{
// like the corresponding constructor
}
Add non-static member function variantions of the make functions like
void IIR::Coefficients<NumericType>::computeFirstOrderLowPass (double sampleRate, NumericType frequency)
which contain the code of the current make ones but call setCoefficients where the current ones call new. The original make functions could remain and use the new constructor internally to first pre-allocate a new Coefficient struct, then call compute on it and return the newly allocated coefficients.
If I find some time next week, I could create a Pull Request with these changes, but some feedback from the JUCE team on what they think about all this would be great.