The actual verilog is often the easy part. Writing a good simulation (see testbench.v and the firmware folder) to make sure that verilog does what you expect takes a fair amount of work. Getting the verilog to synthesize and meet timing is also another large piece of the work. It appears that (unlike a lot of FPGA projects) the author of this has actually written scripts to automate that part, but you can bet there was a fair amount of trial and error to get those scripts correct. There's always a lot of "fighting the tools" involved in this process.

RISC-V, this is the RV32I set of instructions, is relatively simple, e.g. there is no hardware support for integer math errors, overflow, etc. besides divide by zero (http://riscv.org/spec/riscv-spec-v2.0.pdf):

We did not include special instruction set support for overflow checks on integer arithmetic operations. Most popular programming languages do not support checks for integer overflow, partly because most architectures impose a significant runtime penalty to check for overflow on integer arithmetic and partly because modulo arithmetic is sometimes the desired behavior.

At this level, there's no multiply, let along division instructions (which can be OK, the original Lisp Machine didn't have any hardware support for that, the three major "upgrade" features of the LMI LAMBDA processor were speed (Fairchild FAST logic, i.e. 74Fxx parts), an extra bit of address space, and adding a TRW 16 bit multiply chip).

To a noob like me at this sort of thing, their story of how their instruction formats are particularly easy to implement sounded good.

I would see a core like this being used for things like network protocol checksum and segmentation offload or providing a slightly smarter interface to flash chips for a bigger RISC-V core, the instruction set limitations seem fine to me.