According to the docs you link:
The ScriptableSingleton generic class allows you to create 'Manager' type classes in the Unity Editor. In classes that derive from ScriptableSingleton, serializable data you add survives assembly reloading in the Editor. Also, if the class uses the FilePathAttribute, the serializable data persists between sessions of Unity.
So based on this description, the ScriptableSingleton class is used for storing data that you might need for an editor utility.
Say you've built a custom plugin for the scene editor to do some procedural generation. And let's say it needs to do some heavy-duty pre-computation and caching when your assets/settings change, so that it can run at interactive speeds the rest of the time.
If you store that pre-computed data in a normal ScriptableObject, then you have to tell the utility where to look for it. And it gets confusing if someone makes two copies of the asset - which one should it use?
But if you store the data in static variables, then they're lost when you change your game code and reload the assembly, when you enter/exit play mode, or when you exit and re-launch the editor. So you redundantly do the slow pre-processing work over and over, bogging down the editor workflow.
The ScriptableSingleton appears to be made to solve those problems, giving these editor utilities a place to store persistent, easily-accessed information that won't get wiped out by common events like changing a script file.
If I'm reading it right, it looks like you can even store this data outside the Unity project, to share editor utility settings between multiple projects.