Sorry for the late reply, and thank you for the feedback.
The reason I implemented a native PIO_SPI is as follows:

1. Performance and Overhead
   While it’s possible to drive PIO purely from Python, the WIZnet chips require very frequent register accesses. In practice, the Python interpreter overhead accumulates and can noticeably reduce throughput and responsiveness. The native implementation removes this overhead and ensures more stable operation.

2. High-Speed Transfer
   Communication with the Ethernet chips often requires SPI clock rates in the several-MHz range. With a Python-only approach it may be difficult to achieve these speeds reliably, whereas a native PIO driver might make it relatively easier to reach them.

3. Precise Frame Control
   WIZnet chips use slightly different SPI framing depending on the model, and they are sensitive to inter-byte gaps and clock timing. A native implementation provides more predictable timing and precise frame handling.

So while I agree that a Python-only solution is possible in principle, for this use case I found that a native PIO_SPI provides the performance and stability needed.

The W6300 will need library changes for the extra pins to take advantage of the quad SPI?

1. In practice, the Python interpreter overhead accumulates and can noticeably reduce throughput and responsiveness. The native implementation removes this overhead and ensures more stable operation.

Did you try the Python-only version first? I'm worried this is a lot of specific code for us to maintain. Having it in a library of yours using rp2pio directly means you can maintain it easier.