Unique function for each instance of a scriptable object

Generally you don't you would make an abstract class and a different different class for each functionality.. but you could try to make a ScriptableAction.

 abstract class ScriptableAction : ScriptableObject
 {
 public virtual void PerformAction(){}
 }

Then you define all your actions as ScriptableActions and in your Biome you have a reference to a ScriptableAction.

 public ScriptableAction action;

Then you can drag and drop it in for different instances.

Well, depending on what other aspects go into your biome generation you can use even more scriptable objects to act as plugable behaviours. To get a bit more insight I highly recommend this unite talk as well as this older unite talk from Richard Fine.

So your Biom generator could consist of a list of references to other smaller concrete implementations of parts of the generation. That way you can easily setup different biomes by mixing different aspects together. For example MC also has a decorator pattern in place. So that's just a routine / system that applies changes to the already generated terrain. This could mean adding trees, carving caves, distribute ores, adding villages and so on. Of course the more customizable features you want to have the more complex the system gets. However it's much more flexible that way and avoids duplicating code.

Yes in theory you could just use plain old inheritance. However sooner or later you run into the common inheritance issues. For example if you create a "normal overworld" terrain generator and create several subclasses which might just add other features to it, like tree generation for one biome and cacti generation for desert like biomes. Now if you want to create a new seperate terrain generator this is of course possible. However you can not just add the same features you added to your other biomes without copying all the code over. If you seperate each feature into it's own strategy it becomes much more decoupled and flexible. You may want to have a look at the strategy pattern if you have never heard of it. Note that in principle Unity's approach with components follows a similar pattern as the strategy pattern but even a bit more loosely as MonoBehaviours do not use inheritance from Unity's point of view.