Advantages and disadvantages of microcoded vs hardcoded architectures
The distinction between "microcoded" and "hardcoded" multi-cycle control units is a relatively small implementation detail.  The distinction was more important in the 1950s when people were inventing new implementation techniques for state machines.  In modern processor design there are much more important implementation distinctions, like how much pipelining and instruction overlap you are going to try to achieve, whether you are going to speculatively execute instructions, and whether you are going to try to schedule instructions out-of-order.

That said, here's the distinction:  We divide the design into datapath and control.  Here's the picture of the MIC-1 from Tanenbaum's Computer Organization book.  (The image is by Suyog.karnawat, from Wikimedia commons.)  Everything in the design is the datapath except the box in the upper right hand side that says "Instruction decoder and control logic."



The "Insruction decoder and control logic" box is a finite state machine.  The datapath in this example is very simple, with only a single bus, so even an instruction to add two registers and put the result in a third register takes multiple cycles (each of which corresponds to a state in the state machine.)

Each instruction goes through the following steps/states (each of which takes a cycle)


move the PC (Program Counter) to the MAR (Memory Address Register)
assert the controls to perform a load from the memory bus
eventually the memory will return the requested data (which corresponds to the next instruction) and put it in the MDR (Memory Data Register)
move the instruction from the MDR to the IR (Instruction Register).  At this point the instruction gets decoded and we figure out what to do with it.  In this case it's an add operation so we know we need to:
move Ra to the X register
put Rb on the bus (so that it will go to the B input of the ALU) assert the ALU control lines and Mux select appropriately to do an add operation, the result of which will get saved in register Y
Move Y to the Rc register, and then every non-branch instruction ends by incrementing the program counter:
Put the PC on the bus, set up the ALU to increment (Select the MUX to put constant 1 on the A input and set up the ALU to Add) so that PC+1 will get saved in the Y register
Move the Y register back to PC


So 9 state transitions to perform a simple add instruction.

So the "Instruction decoder and control logic" is a finite state machine with inputs from the IR register, outputs are the control signals, and there must be some flip-flops inside to represent the state of the state machine.  But there are lots and lots of ways to implement a state machine.


$\lceil \log_2 N \rceil$ flip-flops (where $N$ is the number of states) and a lot of combinational logic (to calculate the control signals and next state).
$N$ flip-flops with one-hot encoding and a bunch of combinational logic (usually less than with option A, but a lot.)
Somewhere between $\lceil \log_2 N \rceil$ and $N$ flip-flops with some combinational logic of intermediate complexity.


And the combinational logic for the control signals and next state functions can be implemented any number of ways:


As NAND gates reduced (using Quine-McCluskey, or whatever) to sum-of-products form.
As NAND gates reduced to some relatively efficient multiple-level circuit.  (This is probably what people think they mean when they talk about "hardwired control.")
A design using Multiplexers for the combinational logic
A design using Programmable logic arrays (although I don't know if you can even buy these anymore.)
A design where the combinational logic is implemented with a ROM.  (This is probably what people think they mean when they talk about "microcoded control.")  The ROM might be a EEPROM so that it is somewhat easier to modify if you find a bug.


ROMs can get really huge if you're not careful.  For example a ROM-based design would almost always use $\lceil \log_2 N \rceil$ flip-flops, because making the state wider also makes it sparser, which is sometimes good for gates but not for ROMs.  Also, you would only use the opcode bits as part of the address to the ROM, not the register specifiers and such.

Finally with ROMs you might choose to make the microcode word wide (the microcode word produces the entire set of bits for the control signals) or narrow (the microcode word chooses one of a smaller number of possible control signal combinations and then there's a second ROM that translates from that smaller number to the actual required control signals.

So the distinction between "hardcoded" and "microcoded" is only one very small decision that needs to be made among hundreds of design decisions.  And it's certainly not the most important one.  (For example, you could choose to put a second bus on the datapath, which would enable you to perform some instructions with a lot less cycles.)