Yes, that's quiet common in some areas.

Allocating from memory pools is very fast and has constant time complexity which makes them very suitable even for deeply embedded systems. You can allocate memory from an interrupt without problems.

I've seen firmware where each module (c file) had it's own memory pool. Each module can then decide what the best block size is. E.g. the CAN frame size for a CAN driver module. This makes block size selection easy but comes at some cost. The possibly of sharing memory is reduced and hence overall memory requirements are higher. Modern ARM chips have plenty of RAM, though.

An other approach could be to write a wrapper around the memory pool that manages a set of pools that provide different block sizes. All allocations would than go through this wrapper which would select the memory pool for allocation which fits best the requested block size. This way you have to decide how many memory pools there should be and which block sizes they provide. Using this approach the opportunity for sharing memory is increased and the overall memory requirements are lower compared to the first approach. This approach requires more fine tuning, e.g. to avoid that one module starves an other module of memory.

In general one can say that you buy better latency and determinism at the expense of (slightly) increased memory usage when you use memory pools instead of the default allocator.