Any non-real-time operating system will eventually get a little bit buggy around timing intensive operations like I2C or (especially) SPI. Better to have your GPIO operations performed by a dedicated micro that only handles your serial traffic and whatever pin-twiddling operations you need to do. Ideally, your serial traffic is in a binary protocol like MODBUS-RTU, so your traffic parser is as fast as possible.
Bitbanging I2C or SPI is tedious but generally pretty achievable in a bare-metal application. But unless you're hacking your kernel to force that kind of timing fidelity, bit banging on an RPi running Debian is just impossible.
Sounds like this would be very annoying compared to a SBC. You have typically several SPI, UART, I2C, gpio interfaces on the pin header on usual ARM SBCs. Ready to use from Linux via standard API, using DMA, etc.
I once had a very simple I2C operation performed on an Orange Pi running project nerves. I had to add a try-again loop to the I2C operation, because the underlying OS kept disrupting the I2C timing. I2C is generally run between 100-400 KHz, so you'd think it wouldn't be an issue, but it definitely was. You can get around this by patching the kernel to carve out timing protection for those operations, but speaking as a firmware programmer, if I'm patching the kernel to avoid writing a simple arduino sketch, I've made some pretty deep mistakes.
100 khz is still very fast, with sub-millisecond I2C tranfers possible.
You'll have the same issue on any SBC running Linux. You'd need to carefully use realtime process scheduling, if you want more predictable timing on a general purpose OS for such stringent timing requirements.
What I see a lot of is people trying to cram all sorts of shit into a Pi and expecting everything to work properly. I actually wrote a fairly small event-driven kernel for AVR parts a few years ago called XOC "exec-or-communicate" which could do small real-time tasks easily (combinational logic, state machines, interrupt handling) and delegated complicated ones to a host machine over virtual serial port. It was used for a metering system I developed. The AVR side could withstand a complete host failure and reboot.
Any non-real-time operating system will eventually get a little bit buggy around timing intensive operations like I2C or (especially) SPI. Better to have your GPIO operations performed by a dedicated micro that only handles your serial traffic and whatever pin-twiddling operations you need to do. Ideally, your serial traffic is in a binary protocol like MODBUS-RTU, so your traffic parser is as fast as possible.
Bitbanging I2C or SPI is tedious but generally pretty achievable in a bare-metal application. But unless you're hacking your kernel to force that kind of timing fidelity, bit banging on an RPi running Debian is just impossible.