The distinction between user and developer is not always clear in game development. Standard programming techniques like "fail fast" are not always advantageous, especially as team sizes grow.
For example, perhaps your technical artist has screwed up the shader for the targeting outline - broke the fallback, let's say, so it's only loading on SM4 systems, and he didn't notice because he's got a top of the line system. This results in some animations failing to load. Those animations are referenced by a particular spell your combat designer has written. Finally, your level designer is trying to get the spawns in place and those spawns all happen to be able to cast that spell - but now she can't place any of them in the world because their spells aren't valid because the effects aren't valid because the shaders won't load because the designers always have the worst computers.
So your demo isn't ready by 2PM and your investors wonder why you can't even get a single enemy in the game and your project gets shut down.
Or you choose the option where you log the failure but keep trying, and the game plays fine except some enemies spell effects don't appear - but the investors don't know what those are supposed to look like anyway, so they don't notice.
For that reason, I'll almost always advocate the first option - spawn as much of the entity as you can. There are cases for fail-fast - like if the data should never be edited except by people capable of doing builds (i.e. programmers and technical producers) and is always checked 100% at load, or if you're absolutely sure the person responsible for the problem is the person using the editor - but those are not the usual cases, and require a lot of technical infrastructure per se, which you might not be ready to invest in.