Personally I would not want to speculate about a specific game without doing some actual profiling, and even then I would be very careful since I would not want to inadvertently say something misleading or subtly wrong. Therefore I don't think I will comment about Elden Ring specifically.

Now in terms of a generic D3D12 or Vulkan game, there's a bunch of different factors here that can make shaders and PSOs (the two are closely related) rather complicated to deal with. Again none of this applies to Elden Ring in particular since I know nothing about their tech, but just applies in general to any engine:

• Both of these APIs push you towards pre-compiling your shaders from high-level source code to an intermediate bytecode format (DXIL for D3D12, SPIR-V for Vulkan). You can compile to bytecode at runtime, but in practice most games won't do this. Instead they will pre-compile as part of their code compilation or asset processing pipelines, and ship bytecode with the game.
• Intermediate bytecode is just that: it's an intermediate format. It cannot be directly consumed by a GPU shader core: the driver needs to perform another JIT compile step at runtime to convert the bytecode into the native ISA of that shader core. In many cases the driver uses a full optimizing compiler (such as LLVM) to do this step in order to make the final ISA as optimal as possible. Since this generated ISA is specific to the video card and driver, it can't be done ahead-of-time.
• In D3D12 and Vulkan this JIT compile step doesn't happen until you create a full PSO, which provides enough render state to be able to fully compile down the shader to ISA (since things like blend states or MSAA sample counts can require the driver to compile things into the shader to make them work). This can make things tricky if the engine is not setup to know in advance the final render states that will be used for a draw call. In particular it's bad for the old OpenGL/D3D9/10/11 style of setting states one at a time before a draw like a giant state machine: in that case you would not be able to create the PSO until draw time, which as you pointed out is pretty bad time to suddenly stall for hundreds of milliseconds.
• Even if your engine is setup to generate PSOs ahead of time, creating them all can still take a significant amount of time. I know you mentioned you only had 10 shaders in your project, most game engines will have much much much more than that in typical scenes. This can be either a product of needing lots of permutations for performance, or from allowing artist-authored shaders (like Unreal shader graphs), or all of the above. I wrote a whole big blog post on this subject if you're interested: https://therealmjp.github.io/posts/shader-permutations-part1/​
• Even small numbers of PSOs can take a long time if it takes the driver a long time to JIT compile and optimize the bytecode into ISA. It can vary significantly across vendors (as JoeJ pointed out), and it is not something that necessarily scales linearly with source code size or bytecode size (it's very easy to have O(N^2) or worse scaling when it comes to optimization passes).
• Both APIs have various forms of caching for PSOs and compiled shaders that might involve the driver, the operating system, or even the app itself. However all of these can only cache things after going through the initial JIT compile step, which has to happen at least once. And even if there's a cache hit, if it involves opening and reading a file that still may not be fast enough to avoid a hitch if it's happening on the critical path.