Well the silicon was clearly ready, but the microcode was not.
I wouldn't be ready to say that, you need to remember why microcode exists in the first place. There are two parts to microcode: breaking down complex instructions into simpler steps for the RISC-like execution back-end and
providing opportunities to correct or work around hardware flaws.
If the microcode isn't ready at launch, it could be taken as an indication that there were more hardware flaws, more severe flaw, other complications and unexpected misunderstandings of how the architecture worked than expected. The hardware may not have been quite ready but there wasn't time for a re-spin to address it at the source, so they take a gamble on field-fixing flaws with micro-code updates later if they are sufficiently confident about it and cross their fingers that they really do have access to all of the bits they need in micro-code to work around any known and additional issues they find.
Intel promised micro-code fixes for its Puma-6 modem chipset and several months of research later, it was forced to admit that the architecture simply did not have micro-code access to the bits it needed to change to actually fix it. With no software-based work-around forthcoming (at least not until 18 months later), it scored itself a class-action.
With hardware that requires day-0 micro-code updates for normal operation, sometimes you win, sometimes you lose.