I think that most here are entirely missing the point of Lua. "The Lua ecosystem" isn't a thing that makes sense. Lua isn't a standalone language - it's an extension language, and is specifically popular because it doesn't have much in the way of a standard library or built-in assumptions about its environment.
If you can't make any assumptions about the environment, you can't have an ecosystem, because everybody's doing something slightly different. Some might be running every Lua script in a separate environment, some might have every Lua script bundled into the same environment, some might be running Lua on a separate thread so blocking is fine, some might integrate Lua into their application's event loop library. How are you supposed to build a library that serves even some reasonable amount of the userbase's use cases?
It goes beyond that, though. One of Lua's goals is to be implemented in 100% portable C, to the extent that it has no platform-specific #ifdef's (no #ifdef's at all, actually). This means that to use a lot of incredibly basic functionality supported on all relevant operating systems (like, as mentioned in another comment, changing directories), you need (for vanilla lua and luajit on platforms that don't support the ffi) a C library dependency, or a wrapper script (for luajit on the other platforms). This is pretty silly; any user of a platform without a filesystem would surely know that chdir would not be supported.
Beyond that kind of indefensible omission, there is much ecosystem fragmentation and duplicated effort that could be solved by standardizing tools like a package manager without requiring you to install it on embedded targets.
Why would you want somebody to be able to chdir or otherwise manipulate global state in, say, a dialog script for a game engine, though? You probably don't. You probably don't want them to be able to do lots of things. Hence the standard library lacking most things.
Yes, having a package manager might solve some issues, but not for any of Lua's primary use cases. It's not supposed to be the language you write your web app in, or a shell script replacement, or whatever else, and the language developers really don't care about those use cases. It's not supposed to be anything out of the box aside from some syntax and semantics that are Turing-complete and reasonably usable.
Where I've seen Lua used, often even the existing standard library is modified or not used at all due to constraints from the embedding program. What point is a package manager if you can't use most of the packages in many environments? This isn't just embedded ones - this is on the desktop as well.
If you're looking for something more capable out-of-the-box, I'd go for embedding Python or Ruby. Lua simply serves a different niche.
This "indefensible omission" is solved by using LuaFileSystem. Not having it in the core language is not such a problem. Another example is sleep(), which is not portable. You can find a sleep function in libraries like LuaSocket and luaposix.
Fragmentation, however, is a problem. The Lua authors have often refused to "bless" (term used by the community when discussing this) libraries. Roberto Ierusalimschy even said during a Q&A he'd rather "bless" a group of people to do it instead of him.
The problem is, as several people said in this thread, that it is very hard to write a library that fits every use case. Even something almost "standard" like LuaSocket is not used by everybody.
Some people in the community (including me) are trying to reduce the fragmentation. The authors of the two main ways to manage "packages" (LuaRocks and LuaDist) are working together, etc. But I think we will never manage to standardize on One True Library for everything.
I didn't say you couldn't write a trivial library to access sleep or chdir, just that I think it's ridiculous to need to do so. You may disagree, and clearly we can still get work done in the language, but IMHO Lua is suboptimally small, and the local maxima for "tiny yet useful" languages would have a lot more in the standard library and a few "blessed" tools to boot. A language with the goal of implementing in the standard library everything trivial, fungible (one chdir wrapper is as good as any other), useful for most users, and portable across major desktop and mobile OSes (embedded users will know if they don't have e.g. a filesystem) would be a lot more useful yet probably not meaningfully larger than the existing implementations of Lua. Sure, this would mean more stuff to lock down if you're using it as a sandboxed scripting language, but a compile-time flag with reasonable defaults for a sandboxed environment could be provided.
If you can't make any assumptions about the environment, you can't have an ecosystem, because everybody's doing something slightly different. Some might be running every Lua script in a separate environment, some might have every Lua script bundled into the same environment, some might be running Lua on a separate thread so blocking is fine, some might integrate Lua into their application's event loop library. How are you supposed to build a library that serves even some reasonable amount of the userbase's use cases?