Just because this is done in verilog doesn't make it emulation. It's probably just machine placed and routed. Almost everything is these days in digital design.
https://github.com/rejunity/z80-open-silicon/blob/974c7711b2...
Instruction decoding on a real Z80 CPU doesn't work at all like that :)
A non-emulator-approach would probably use the reverse engineered Z80 netlist from visual6502.org to base the design on, no idea if this is even doable with modern chip design tooling(?)
If anything, the netlist is useful to verify the Verilog implementation (as is mentioned here in the readme: https://github.com/rejunity/z80-open-silicon?tab=readme-ov-f...)
Verilog isn't imperative code, to be executed one line after another in sequence. It's a description of combinatorial logic to be wired up to inputs and outputs, gated by a clock edge. Everything in the Verilog module "runs" at the same time, there's no jumping to a branch, there is instead logic to wire up one "casez" block or another to the relevant output signals. All the blocks are lit up, only one has its output selected to connect to the output wires.
The PLA block is more convenient to a hardware engineer laying out a CPU by hand. You can see everything together and trace execution easily. Downstream consequences of decode are done elsewhere. Upstream decode of control signals are done elsewhere. The Verilog is more convenient to a hardware engineer relying on tools to route logic: the Verilog does more than the PLA - it does the additional control signal inputs, and it does the downstream consequences like determining which register(s) are used on which register bus. It's laid out more like a software decode of the instruction bits because it's easier to think about groups of opcodes than individual ones.
In execution, though, they wind up doing very similar things.