Yes there are good reasons to increase it, but not to reduce it (because then we are wandering in unspecified/unareas and the default implementation will be full of severe bugs).
It may happen sometime that Lua will need to increase this strict minimum value (probably for integrating Lua with native code calls requiring more complex calling conventions and needing more space than just a basic C function call, and without the need to switch the current stack in use and to acquire and release an exclusive lock on some external stack objects, which could be costly in terms of global performance and concurrency between many concurrent Lua threads trying to do the same thing.
[ It is known that such thing requires a serializer, and safely serialized accesses require delegating to a single critical thread to coordinate the demands; but basic Lua threads are cooperative and not really concurrent, so there's normally no need to serilaize them... except if these threads should handle callback events coming
asynchronously
from the underlying environment: these callbacks would also need to transition via a single coordinating thread and could delay the return from the callback to the OS in a way that could break its strict requirements for the time taken by callbacks). ]
But we could decouple the definition of this strict minimum from the definition of the minimum size that will be actually used by lua_checkstack (when compiling this module, there must be an compile-time assertion that will test that the specified definition respects the normative definition).
LUA_MINSTACK for now has been kept very low to ensure that the initial total size of a stack can also remain relatively low and still have large enough space for productive code in very memory-constrained environments that don't want to waste memory ressources, including in large servers hosting many concurrent applications, or for applications using really many concurrent threads (however for this case, servers can now use large 64-bit addressing spaces, which can be paged out if needed, and we are far for reaching the need to be very severe on memory ressources usable in a productive thread.
