"mw" is the variable giveing access to documented Lua API of Mediawiki, it is preloaded at start of all modules written in Lua, and also accessible on its console (when editing a module page). You can develop yout lua module directly inside this console, test it, inspect variables, or just type any Lua statement, plus a special statement "= variable" to print one or more variables (using their tostring() value, so for tables you just see "table" in the console. To log the content of the variable, the preloaded "mw" object has some fucntions (written in Lua), one of them being "logObject" which can inspect the structure of tables, it cannot inspect the content of functions, so instea they are displayed as "function#id" with a numeric id that can be used to determine in the logged objects if they refer to the same function or not/
Wikimedia wikis that support Lua modules (user-editable in the "Module:" namespace from which they are loaded), have this console: even if the module page is protected, you can still edit it in read-only mode, but the console is active and allows testing the module or any Lua code (and you have access to the libraries documented in Scribunto, whose link is provided in that same edit+console page, "Scribunto" is just the name of the Mediawiki plugin that just implements the sandboxing needed fur using Lua from any Wiki page, and you can only use the listed supported libraries ("mw", "string", "table"... and load other modules only from the "Module:*" namespace, not from external sources and not from files on the server hosting it).
But clearly the intent of Wikimedia was to choose an alternative to _javascript_, using a smaller scripting engine that could be used in millions pages viewed and edited by millions users: Scribunto allowed such integration by implementing the necessary sandboxing without risking to compromize the hosting servers and the rest of the Mediawiki software and PHP engine running it. Lua was then embedded in PHP with Scribunto (itself written in PHP with help of some PHP plugins written in C; but wiki users have no access to the PHP level which would exposes too many private data and internal costly APIs to the dabatabase server storing and indexing wiki pages, modules, images, user profiles, private mail boxes, direct access to post to mailing lists, private server access logs, security secrets, admin rights, ...).
May be this is clearer: most users don't need to install Lua on their host, many have learnt Lua and experimented with it after seeing it in Wikimedia sites where it is now abundantly used. You can start experimenting Lua directly from the wiki. The modules in Lua also have their own documentation page (normal wiki pages), automatic unitary tests, extended tests, talk pages to discuss issues or propose/explain changes...
This allowed the Lua community to expand a lot around the world compared to what it was before (only in some games and for a few geeks aware of the Brasilian new language). Now Lua is a major language, but it's still in its infancy, not as much respected as PHP, _javascript_, Python, Perl.