[Baertram]

Yep, as Scootworks and Sharlikran said. AccountWide are preferred.
I'd either use LibSavedVars for new projects I guess.
So far I always had used my own SV structures.
AccountWide generel settings to store which way of SV saving should be used, stored with a special version (shouldn't change at all in the SV) in a special subtable e.g. "BaseSettings".
If BaseSettings.Accountwide enabled: AccountWide settings for the addon data stored in the "Defaults" subtable (or server dependent, see below) with a version that might increase due to SV changes needed.
If BaseSettings.character enabled: CharacterID (Do not use the name anymore as it's not rename safe!) addon settings stored in the "Defaults" subtable (or server dependent, see below) with a version that might increase due to SV changes needed.

Sometime you need to mix those.

Addon use-case depending SVs
"Depending on the addon" it makes sense to "only" save character dependent -> e.g. addons which are class dependent, or junk addons (1 character shouldn't junk special items as he/she collects them for crafting or whatever).
Or "only" account dependent.
This also depends on if users play with ESO+ or not imo as they often won't use the bank and cannot use the CraftBag, so the "mule" characters store the items, and Inventory Insight e.g. shows what item is where.

In the end each user plays differently, so their SV needs are differently.
That's why I try to always provide both/all possible ways of saving SV, where it makes sense (at least for new addons).

Server dependent:
For new addons I'd also always add the "GetWorldName()" (or similar) to save the addons server dependent (EU Megaserver, NA Megaserver, PTS) as users meanwhile tend to play on both (EU and NA) servers. One can add this as last parameter to ZO_SavedVars:NewCharacterIdSettings, or as 2nd last to ZO_SavedVars:NewAccountWide e.g. so that a subtable with the server name is created in the global SV table.

Multiple account support
They even often got more than 1 account.
Within FCOItemSaver I therefor even added the "AllAccountsTheSame" switch to the accountwide SavedVars (it uses the last parameter of ZO_SavedVars:NewAccountWide, which if not filled uses GetDisplayName(), and else it uses your String as constant) so that all accounts used store the settings server dependent but all the same for no matter what @account your are using).

Combinations:
Some addons even need a combination of character and account wide settings (or at least the benefit from them), e.g. save some looted items etc. as character settings but save general settings account wide how the addon looks/feels and what it does with those looted items.

Not using ZO_SavedVars wrapper
You could even not use ZO_SavedVars wrapper and save the SV date directly to the global table which you have added to your manifest file's ## SavedVariables <globalTable>.This will strip the precreated sub tables in the SV. e.g. just use GetDisplayName() and GetCurrentCharacterId() yourself to build a SV structure of your needs.



In the end, imo, it really depends on the usecase and features of your addon!
But LibSavedVars should handle the most standard cases.