Not actually a noticed issue. Just going through my logs with blame installed and passing out some Blame Reports:
https://pastebin.com/cAdzFb1V
Simpleores2-1.16.4-2.4.2.4
SimpleCoreLib-1.16.4-2.0.3.2

Hello! I am the maker of Blame and I can explain a bit more of why ConfiguredFeature should be registered. This can be an issue for mod compatibility as under certain conditions, unregistered ConfiguredFeatures can basically prevent other mod's registered ConfiguredFeatures from spawning if in the same generation stage.

By that I mean, if mod A adds an unregistered CF to the ore generation stage and the biome's codec reaches it first, it will choke and basically nuke mob B's registered CFs afterwards. Here's a case where BetterCaves forgot to register their CF and caused several CFs from Oh The Biomes You'll Go to stop spawning in the world: YUNG-GANG/YUNGs-Better-Caves#75

Here's a more detailed explanation of why this happens in the biome's codec:

Specifically, when you call .withConfiguration on a Feature, you create a ConfiguredFeature. This is what should be registered to the WorldgenRegisties at mod init (you can do it in FMLCommonSetupEvent so you have your config ready too if it is needed).

Anyway here's an example from my mod RepurposedStructures of me registering all my ConfiguredFeatures.
https://github.com/TelepathicGrunt/RepurposedStructures/blob/584433a0745338802c84e9f498dc063c1f5505f8/src/main/java/com/telepathicgrunt/repurposedstructures/modinit/RSConfiguredStructures.java#L72-L74

I hope this helps!

From the log, it seems ConfiguredFeatures using these blocks are not registered so this might help you know what needs to be registered:

simpleores:adamantium_ore
simpleores:copper_ore
simpleores:mythril_ore
simpleores:onyx_ore
simpleores:tin_ore

That's very helpful, I didn't even know this was an issue. Ore generation in 1.16.4 is not well documented, to put it mildly. I am working on different approaches right now.

Also, what is Blame, and how do I tell if a configured feature is registered? It doesn't seem to show in the logs.

Blame is a mod I made which you can download here. (best ran in production rather than dev environment but lmk if you do want to run it in your mod's dev environment. There's a few steps to do to make it run in dev) https://www.curseforge.com/minecraft/mc-mods/blame

The actual error in-game is hard to reproduce on demand but it would happen if your mod adds the unregistered ores and then another mod adds registered ores afterwards so mod load order matters and all. Better to register it.

A good way to tell if it is registered is place a breakpoint that triggers while you are in a world and then open up the world object, find the dynamic registry stored in it, find the configuredfeature registry, and see if your ores are in there. But really, as long as Registry.register(WorldGenRegistries.CONFIGURED_FEATURE, new ResourceLocation(ModMain.MODID, "configured_ore"), ORE_CONFIGUREDFEATURE); is ran in FMLCommonSetupEvent (in an event.enqueue), you should be good to go.

Hmm. I did make a minimal example in MMD discord for doing ores in 1.16.2+. I'll just copy and paste it here in case it helps.

The bare minimum to generate a new ore in 1.16.3+ is:

public static ConfiguredFeature<?,?> CONFIGURED_COAL_ORE;

someplaceElse{
  CONFIGURED_COAL_ORE = Feature.ORE.withConfiguration(new OreFeatureConfig(OreFeatureConfig.FillerBlockType.BASE_STONE_OVERWORLD, Blocks.COAL_ORE.getDefaultState(), 17)).range(128).square().func_242731_b(20)
        
  Registry.register(WorldGenRegistries.CONFIGURED_FEATURE, new ResourceLocation(StructureTutorialMain.MODID, "coal_ore"), CONFIGURED_COAL_ORE);
}

public void biomeModification(final BiomeLoadingEvent event) { 
   event.getGeneration().getFeatures(GenerationStage.Decoration.UNDERGROUND_ORES).add(() -> CONFIGURED_COAL_ORE);
}

Feature.ORE is the feature that is doing the ore placing. I call withConfiguration and passed in the config for the ore feature. This includes which blocks to replace (BASE_STONE_OVERWORLD), what block to place (COAL_ORE), and how big the vein is (17).

Then the placements comes in as methods chained on the end. We do range, square, and the count (which is func_242731_b) in that order. This is important as the game will go through the placement backwards. So here, count (func_242731_b) is ran and creates 20 positions. Then square is ran and will randomize the x/z coordinates of the 20 positions so their x and z is a number between 0 and 16 in that chunk. Then range is ran last and will randomize the y value of the 20 positions so their y value is between 0 and 128.

Now after the 20 positions are made and is randomly spread out across the chunk, the Feature.ORE's generate method is ran on each of those positions and that's where the coal blocks are places if there is stone there (stone determined by BASE_STONE_OVERWORLD).

Also, we register the ConfiguredFeature as well so it doesn't blow up other mod's configuredfeatures. You can register them anytime before a world is made so mod FMLCommonSetup is safe if done in an event's enqueue.

Revamped SimpleCoreLib's supporting utilities, SimpleOres2, Netherrocks, OnlySilver, SimpleTungsten, and HaditeCoal, all of which suffered from this issue.
SimpleOres commit 658f38f finalized the fix.
SimpleCoreLib commit ec34c66c99ec0a92748a5f6b65199b7e50b62c55
OnlySilver commit b6104634dcc885ddc1072448a0e5c46f8c660f9d
SimpleTungsten commit e15a6b5ed80949c4f7826a6f5da887835ec10e37
HaditeCoal 2ee720a643f45b07dfe8a91983c0dab91da32da3
Netherrocks ebcadd3601d90506a627d919ea83824d96ce148f