Need opinions on handling Scriptable Objects

Heyo!

Quick general note: For discussions and opinions, you're likely to have more luck in the forums, as Unity Answers is for... well... answers to questions. I'll answer anyway :)

ScriptableObjects have one thing to offer for you, and that is that they're UnityEngine.Objects that you can freely create and serialize in the editor. For example, but not exclusively, into your assets. Thus, you can use ScriptableObjects to define data (like item stats) in the editor and have them moved over to your build. A ScriptableObject that is created at runtime does not do this and thus does not have any sort of advantage over a plain ol' C# object. The only thing a ScriptableObject that you create during runtime will do is make garbage collection more annoying, as it exists both in C# land and in C++ land, as all UnityEngine.Objects do.

Because of all that, it's common practice to not use ScriptableObjects like regular objects. Most types of SOs in the wild are immutable data containers, like the static description of an item class. An instance of that item, when generated during the course of the game, would not be represented by an SO. But the item instance object can of course keep a reference to its item class SO in order to have it store the static item data.

There's also the approach of only using the identity of an SO as the data, while having the SO contain dynamic data (see here, great talk). This approach uses the fact that you can drag-and-drop inject SOs into other objects rather than having important data serialized into them. But in this approach as well, the SO would not be created at runtime. It simply gives you no advantage.

Instead, just create regular C# objects if game design dictates that an object is created during runtime. Feel free to have all sword instances reference the "sword class" SO that contains some common data for all swords that a designer can set up in the editor.