It looks like the Raspberry Pi is generally accepted to be capable of ~14MHz reliably in a true GPIO mode, so at least on paper it should be able to handle SCSI-1 and SCSI-2 "Fast SCSI" speeds. It's not clear to me which variant this project supports.

The Pi has enough GPIO pins to support the 16 bit SCSI-2 "Fast Wide SCSI" variant but the schematics here are just for 8 bit "narrow" SCSI.

There are also certain pins on the Pi with specific hardware I/O capabilities that can transfer data faster which can be bodged in to working for a lot of things they aren't intended for, see also the RGB LED control setups and such, but I don't think those will be relevant to this use case.

Why are the gpio pins so slow? Is it assuming overhead from an OS on the Pi or something?

Because GPIO for communication protocols is what is termed "bit banging", normally for high speed communication stuff you have a dedicated ASIC that handles all the low level signaling itself and presents a high level (possibly DMA) interface to the CPU.

With bit banging/gpio you are using the CPU itself to write/read the raw binary signal of the GPIO, usually with no buffering. This involves tight loops and polling and is slow because the CPU must marshal and construct all signaling (including timing!) in a synchronous way, bit by bit, rather than just dumping a block of data into memory somewhere and having a high level ASIC deal with it (or reading said block).

A good analogy might be writing your friend a long note and then having him read (The high level interface) it vs phoning your friend and sharing the note, one letter at a time.(the low level bit banging interface), which do you suppose would be faster, and less demanding of your attention?

On top of all that, remember that this project is doing that reliably enough to use as a disk while sharing CPU time with the rest of the system. It's not running on a RTOS or doing bare metal trickery, so achieving tight timing is really hard and you end up wasting a lot of CPU time just doing that.

I believe they are stretching the envelope a bit. ~10-20MHz is probably the reliable top end for the RPi GPIOs, and even early SCSI standards well exceed that at 5MB/sec. That's taking the rather naive assumption that 20MHz is 20 mega bits (not bytes)/sec. Various encoding ideas could make that better, or worse.

This is a cool dancing bear and all, but I would stick with the microcontroller implementations for real needs. This is cool to experiment with.

SCSI2SDV6 is supposedly capable of 10MB/sec. There's also a guy that designed something with a very capable teensy and a real NCR 5380 SCSI controller. https://www.pjrc.com/tiny-scsi-emulator/

Edit: The Teensy is pretty impressive in this general area. Teensy 4.0 is a features an ARM Cortex-M7 processor at 600Mhz, 1024K RAM, with lots of community support, and it costs $20. You can imagine it blurs the lines a bit on "microcontroller". Bitbanging GPIOs, in bare metal mode, on it will likely work a lot better than an Rpi/Linux. https://www.pjrc.com/store/teensy40.html

SCSI is 8 (data) bits wide plus 9 control signals at 10 MHz, so if the RPi can latch 17 GPIOs at 10 MHz I guess that's good enough.

It can drive one at 10MHz. I haven't seen any parallel attempts. I assume it's slower.

Will be fine and still show increase upon the era they are emulating.

A USB based solution may of proved more portable and sellable though IMHO. Though that market catered with many SDcard SCSI HD emulation dedicated adapters.