Overall a good idea. It's easy to say I'm just developing an addon all by my lonesome so what's it matter? I think that's the wrong way to view addons. It's crowd sourcing. If you're the only one that ever uses your addon then do whatever you please, but if you're going to release it then follow a few conventions.
Topic: Libraries
I have mixed feelings on libraries. Kudos for Seerah getting LibStub out early for a simple, but essential, function. LibStub doesn't require you do either, just one. The library can be a separate addon or included with an addon using it. So it's more convention. I think there's two cases where it's a good idea to be a separate library. One is media libraries or databases where the size can be substantial. The other is where the library provides an interface for the user. ZAM Stats is an example of that. It's not a library, but should be. It should be using LibStub and not ZAM_Stats. It really is a library with an example of using it.
So I don't think there's an always this way or that way answer, but, rather, it depends. I think there should certainly be guidelines to help developers understand when they should choose which.
Topic: Setting Names
By settings names I assume you mean what displays on the system/setting menu using LibAddonMenu. I certainly have encountered wtf is that? One problem though is what the user sees in the ADD-ONS menu is the Title from the manifest. So I think you need a standard for that, like "name - version{ - author}{ - description}. Name is the directory name for the addon. Version the version number as seen on ESOUI to make it easy to check when you need to update an addon. Author incase you have a bunch of addons from the same author to facilitate getting a list to check versions against. Description for when name is cryptic. The settings should then be description if present, otherwise name. It should be clear to the user what the settings are named from the addon list. You have a Description in the manifest so any additional information you want to add can be put there.
Separately LibAddonMenu needs to expand. Personally, all that should be under settings is "ADD-ONS". Clicking that then gives you a list of addons. That, preferably, a real list rather than a menu, i.e. like a file manager. You can filter, sort on columns, and such. Selecting an addon then pops menus like now, or alternatively a custom dialog. A custom dialog just handles some configurations better. I include that here because there needs to be some standard for that list. A way to pull the needed information from an addon. Not that I expect Seerah to do that anytime soon, but, presumably that addon is going to grow. Since lots of addons are already using it the ability pull the data as it grows rather than addons having to push it makes that easier. So I think there should be a convention for including data in a standard location for use by an addon manager. LibAddonMenu isn't the only possibility there. An example of an alternative one is an addon that tracks down who is polluting the global space by enabling and disabling addons and reloading the ui.
Topic: Saved Variables
I'm really baffled as to how Seerah avoids saved variables since, as far as I know, it's the only way to write a file. I assume Seerah actually means per character saved variables. My view is you use the simplest means possible to accomplish the task. When there is no actual sharing between characters then use per character rather than needlessly complicate it by adding subtables for users. All that accomplishes is changing the structure of the saved variables file. You can load those files into an LUA session external to the client. When there's no actual communication between characters make it clear by using the means provided.
I haven't really played with those function so I'm not sure what the parameters do. I understand it enough to use saved variables, but I'm not sure what happens with multiple calls and as a result of changing parameters when there's an existing saved variables to load. The details of that do matter. Some convention on session names, versions, defaults and profiles is needed. A convention for the name as well. Personally, addon_DB, addon_SV or addon_SavedVars where addon is the directory name for the addon. You can't really just have one global since saved variables is another. While you can pick up the variable name from the manifest it makes utilities a bit easier if you just use one.
Also within the saved variables a convention would be nice. Like if you need to share data between characters have "Characters" and "Account" keys. Account has stuff that applies to all characters while Characters has subkeys by the character name. Within those conventions such as options go in Options, history goes in History, data goes in Data, data to be imported in Import and data to be exported in Export. Export is for doing things like uploading your stats to a guild website. Import is from bring in databases such as node locations for addons such as Harvest Map. Some, like Options, should have some standards if certain options are supported, like window size and position.
Topic: Formating
Coding standards certainly. That, to me, would include naming, i.e. local variable/functions, global variables/functions, modules, keybinds, ect. Commenting as well. It should be easy for another programmer to pick up your addon. Some saves errors. Like I ran into naming a function the same as an API function that function called resulting in infinite recursion. I should have stuck them in a local table so there is no chance of such conflicts. As mentioned conventions also help with utilities. The programmer you screw may be yourself in depriving yourself of use of a handy tool.
I don't agree with stripping white space and such. Programmer automate thyself. If you want the white space stripped out then strip the white space out as you parse it. It's senseless to make the source difficult to read so a parser has an easier time at it. That's pennywise and dollar foolish. Spend hours trying to decipher illegible code to save yourself five minutes modifying the parsing process. The LUA manual lists the BNF definition of the language so you can cut and paste it into a parser. So, no, make it easy to read, not easy to parse. Conventions are just used for meta data, what's not in the code, i.e. a comment explaining what the purpose of the function is. Naming conventions are memory aids to the programmer.
Topic: Globals
There should be only one. Ok, maybe a few. It's a pointless debate across many languages. It's pointless because one variable can contain all your other globals. i.e. glob.this. glob.that and glob.theother. That said you actually need more for an addon. Your saved variables have to be global, the function you call creates them as globals. Otherwise they don't need to be. Your top level windows are global. Your key binding entry point has to be global. You need a global handle for the addon as well, logically the one global. One can debate whether than should be a table or class. Class rather complicates it for those that don't use classes. With those that do exposing a table is blasphemy. That one though should be the directory name for the addon.
I see far too much garbage polluting the global space. any()? Wtf is any? Any what? All I know is it dumps cryptic messages to the console and goes on and on and on. This is a particular problem at this stage. Documentation is incomplete and I have to browse the global table to find what I'm looking for. What I would really like to see is just one global for all addons. Every other addon then has a subtable within that. That would keep the global space as clean as possible.