The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
It's only scope, certainly how I used it, was within the function - scope was never a problem. Memory wasn't humongous, then, so allocations were done with care, anyway. There was expanded and extended memory.* It's built in (usually) and automatic. About the only complaint I found really valid is that it's existence in a compiler is not (or was not) guaranteed as it was an official standard. It happened to be everywhere I was (QuickC, MS-C, Wacom-C) on DOS and NT, manly;
Now I live in a stateless world of web development. I will say, however, that with the 400 users, an occasional server request gets an out-of-memory error. I increased it in php.ini a couple of times, but for the most part, the DBA and I share info and he forces filters them to not ask for a million records. A better long-term solution.
*I made a page-swapper so I could access lots of it smoothly beyond the 64K in the original page frame.
Simply put - know what you're doing when you do it. Don't free() it - well, duh! That's the point of using it. Beware of stack overflows. Always keep your wits about you with memory usage. Don't use in recursive functions or loops. In a loop, index the allocations into an array of pointers, or, if you want to reuse the same one, allocate it before the loop . . . just like the other memory functions.
Seems standard enough - for the grownups in the room
Don't use alloca(), it's not part of the C standard.
One of the problems with stack allocation is on platforms like the ESP32 and most of the arduinos, they don't give you a lot of stack space. I know usually one grows up and the other grows down but I run out of stack declaring 2kB blocks sometimes so there might be some kind of artificial limit.
I see you're using both #pragma once and #ifdef include guards. Is that really necessary? GCC supports both, going back to at least version 4.8, so the #pragma doesn't even need to be wrapped in an #ifdef _MSC_VER. But maybe you know something I don't, or maybe you're using some other compiler that doesn't understand the #pragma?
Also, picking nits, since I have nothing better to offer, I see that this is a memory pool for contrained memory environments. That must be a constrained, contained memory situation, correct?