Yes, it happened. MIPS I (R2000/R3000) did suffer from Load Delay Slots. In practice on R2000, on cache hit the next instruction would typically see the old value of the load-result register; on cache miss it would see the load result. So you couldn't usefully take advantage of it and there were no on-paper guarantees of anything, unlike on the Mill (*1).
Other than MIPS, the decision to use load delay slots was never an issue. Mostly because inserting a delay does not really save much hardware. Stalling the pipeline only needs one (or two) rather simple comparator checking if the previous target is used as source in the next instruction.
Detecting dependencies by adding a little logic can be used to kill two birds with one stone as any code, independent of ordering will run, while at the same time 'intelligent' instruction ordering can be used to take advantage of the load delay.
This method has already been used by (e.g) /360 in the 70s, and assembly programmers did take care thereof (or not, depending on their quality).
For RISC CPUs this logic can, for all practical purpose, be seen like an automatic 'insertion' of a NOP. Something otherwise the compiler had to do whenever it couldn't find an instruction to move into the load slot.
A simple addition like A+=B; would create at least two load slots (plus maybe a store slot) which more often than not can't be filled:
L R1,VAL1
NOP
A R1,VAL2
NOP
ST R1,VAL1
This is by no means a rare kind of code - programs are full of such lines.
Bottom line: Load slots bring almost no improvement but add considerable code bloat. (*2)
The whole situations of load delays differs a lot from branch delays, as the load delay happens to data access in linear code execution, not stalling code fetch. In contrast a (conditioned) jump instructions always needs at least one additional code fetch cycle that can't be avoided - or more exact discard the already fetched next instruction without using that cycle for operation. A branch delay slot means nothing else that this already fetched instruction gets executed. This situation does not exist in linear, non-branching code.
So one can just speculate why the R2000 had that load delay slot. IMHO they tried to make it more simple than it has to be. They even named the ISA after this fact: MIPS = Microprocessor without Interlocked Pipeline Stages means it doesn't stall for anything, except unpredictable long stalls (cache miss/RAM access).
Later, when the load delay slot was removed (MIPS II / R6000), existing R2000/R3000-compatible code was full of NOPs in cases where the compiler (or optimizing assembler) couldn't fill the load-delay slot with useful work. These cases were not as rare as MIPS architects may have hoped. It was not helping anything, only bloating the code.
*1 - Unlike the Mill architecture where a load instruction can indicate how many instructions later the result should be ready, allowing use of the old value for up to a few instructions, and reuse of the address register. The Mill is still a paper architecture, though, not a CPU that actually existed.
*2 - Same is as well true for branch slots, except they happen less often.
