WHERE
ENV["HOME"] / Documents
Actually NOT. On MS Windows at least, the name of the user’s "Documents" folder is localized into the user’s system locale language. So you’d need to call a Windows SDK function via either Fiddle or Win32OLE (accessing the Windows Scripting Host Shell and it’s WshSpecialFolders object) to get the proper pathname.
For this and the reasons Christina explained above, it’s actually the worst of the ideas that has been suggested.
%AppData%
This is WHERE I advocate saving plugin settings, regardless of the data format.
On MS Windows normal users will have read and write permissions for these folders.
True, also because users do not understand why their plugin settings are not “brought forward” to the next SketchUp version when they are saved (transparently to the user) in a versioned SketchUp %AppData% sub-folder.
Putting your plugin settings in your own company %AppData% folder path, solves this, and user will see their settings apply from version to version.
The downside, is they’ll begin to expect it from all plugins. 
%ProgramData%
Do not have an opinion for Mac (not being a “Macite”,) …
but on MS Windows normal users do not have write permissions for folders in this path.
Data saved here is usually done by installers which run with elevated privileges.
They will have read permissions, so this location is fine for data that will not change after install, and will only change later when the next version is installed.
On Windows, there is also a “Default” user account that a plugin can save the base settings to, and when new user accounts are generated they’ll get “the default’s”. (These defaults are also usually written by installers running under elevated privileges.)
Plugin Subfolder
Agree (with Thomas,) and also for the reasons that Barry and TIG talk about with regard to the ever changing extension “security” headaches.
We avoid this by using our own plugin data directories, beneath our own company data directory, located in the proper place which is %AppData%.
Sketchup::read_default() and Sketchup::write_default() - shared location
We discussed in that thread the pitfalls that have always plagued the API’s Sketchup::read_default and Sketchup::write_default methods.
This is one of those things where I must disagree with John. Basically the API has failed us, and continues to do so with these methods.
- All the historic problems with their use still exist, despite years of complaints by developers.
- Future fixes cannot help with plugins running in current or past versions. (Gary avoids this by not using these 2 methods at all, so he and his plugins are all set no matter what happens to these methods.)
- These two methods are untrustworthy, just from the fact that their API documentation is incorrect and has been for years. (Add to this, that these methods under went a big change in the last version, but their documentation was not updated.)
- They even changed WHEN the settings were written to storage, without any notice.
This is not developer friendly !
I’ve lost patience with regard to these methods. They are just junk to be blunt !
These methods work the way they work, because this is the way that the Trimble team extension’s need them to work for their “shipped” extensions. So fine, I leave these methods to the use of the “shipped” extensions then.
And I really no longer have any care whether they work or not, or get any nifty new overhaul.
With all of the better alternatives … why should I ?
FORMAT
CSV
I do not know what Excel would have to do with plugin settings. It shouldn’t.
Ruby has a CSV library that is part of the standard library (at present.)
If you are afraid of users opening, tweaking and saving your settings with Excel, then code defensively.
Most users will not know how to make the %AppData% path visible as it is hidden by default on Windows.
If they are smart enough to find it, and dumb enough to not make backups when tweaking a file, then it serves them right if they have to re-install the plugin.
Your code having fallback routine that re-creates the settings file regardless of format, is a good idea. (Files get corrupted sometimes.)
JSON
I think I made the best arguments for JSON in that thread, and no need to repeat here. (Interested users can read that thread.)
And I also agree with sentiment here that reinventing a mechanism to save and restore data is kind of a waste (unless plain text is too large for say saving into the model’s attribute dictionary, and you want to compress the data.) The various text formats and their libraries should be used (ie, JSON, CSV, XML, YAML, etc.)
TEXT - Custom
But I won’t poopoo Garry’s use of a custom text format either. If it works … it works.
And he is not reliant on any library at all.
YAML
I also know several developers who prefer YAML files. And that is also fine with me.
They are a bit more terse than JSON, but still human readable.
PStore
The main problem (I think I was told,) with PStore is it uses Marshal.
Also someone else, a Mac guy, either Steve or Andreas explained that it has some pitfalls of it’s own.
(I’ll try and find the link to the quote and put it here.)