At the top of every module script, there’s always a “local module = {}”, but in every tutorial video I’ve seen, and every DevForum resource I always see that it isn’t used, and if people want to put a table inside of the script, they never use the table at the top and instead create another one?
Sorry if this was kind of confusing, but any explanation would help.
To completely answer your question, I must explain some stuff about tables first! At the end, I’ll tie it in together coming back to your original question.
In my opinion, this (table functionality) is the neatest part of Lua. In Lua, tables are data structures that can store any type of data. This includes functions.
You can see an example of this on line 13 of the code you sent. The developer sets an index called getPickupBonus to a function which returns the rarity multiplied by the default multiplier. PickupManager is storing this function! Now, if a developer had this table, they could simply write PickupManager.getPickupBonus("common") and they would be returned the value 12.5. This table stores this function, and although not shown in the example you provided, it can store many other things, such as strings, numbers, and even other tables.
Now you might ask, how is this at all useful? Why do I need to store a function, when I can just call it from within a script? Notice the last line of the code. The ModuleScript returns the table. This return essentially serves as a means of “exporting” the table to outside of the script. Now, if you wanted to call the getPickupBonus method from a completely different script (outside of the ModuleScript), you could simply require the module script, which would return the PickupManager table, and call PickupManager.getPickupBonus("common") on it to receive the value 12.5. The major advantage of this is that you don’t need to have the getPickupBonus method with your server script! This system of modularization separates and organizes code.
So back to your original question, the table is not ignored. The table essentially acts as a giant storage of information that the ModuleScript can put stuff (tables, numbers, other data) into. Then, this is exported at the end for any other script in the game to use!
Interesting bits of info on Modules, whether you know it or not:
#1 when you require(someModule) within multiple different scripts, the code in the module script itself will only ever run once. So it’s a good way to have some code that only ever runs once, even if many scripts are require-ing it.
#2 Since a (particular) module script will only ever run once for the runtime of the game, you might ask: “So how does require(someModule) return a table each time it’s called?”. To which I say: "idk exactly what it does, but it appears that it stores the table and just gives you the table each time you require it.
So again, the module only runs once as a form of initialization; to initialize the “module table”. And then the module script holds onto the table and gives the table reference to each script that require-s it.
#3 Because of the “run only once” behavior, you could use modules to setup some global events, and assure they only happen once. So you might not need the module table that is given in the template. But why people don’t delete it? I’m not sure.
Also, you can have a module script return other things other than a table. Like you could have it return a single function, or a number, string, etc. But you get less out of it than if it was a table