[1] Not because of often-called "risc like" microcode engine, but because the most complex addressing mode on x86 usually decodes two microinstructions, and decodes in single cycle. In comparison VAX needed separate pipeline for instruction decoding.
That's how the VAX 9000 and NVAX did it. It's not the only way. It is absolutely possible to decode a number of normal VAX instructions in parallel using a pipelined decoder similar to x86 decoders. It is also possible to use a µop cache similar to many x86 and ARM implementations.
Fallbacks are only needed for the weirder addressing modes and for instructions that positively beg to microcoded (system calls/protection level transitions, some bit vector stuff, COBOL decimal stuff, block copy/scan/fill/compare, probably POLY) and startup and interrupt/exception handling.
DEC never did this but they absolutely could have.
DEC didn't try to parallelize the decoder further because it already could face 56 bytes for a single instruction, and the NVAX design was costly as hell. x86 in comparison has limit of max 15 bytes per instruction, and most instructions in x86 code fall in 4 bytes