So I guess this raises the question why a native port?
Good to know that it works natively with the Arduino port now!
As to your question, I am working towards designing a consumer product so reliability is important. The Arduino port code base is pretty large and it's easier to debug my own code that has the bare minimum of things my project requires. Besides that:
1. When I first got going with the ESP8266 the Arduino SPI libraries were pretty much non-existent so I didn't have a choice initially
2. Because of #1, I'm now very familiar with the Native SDK, so I can easily make any sort of customization and not have to worry about breaking Arduino code, or vice-vera.
3. I still don't trust the Arduino port with regards to handling interrupts, or long-term stability.
4. Overhead. I'm curious how much Arduino really adds, but since I've already written it in C I don't see the benefit of switching.
5. Code portability. ESP32 is on the way or I may switch to a different platform entirely.
6. Just the overall idea of using a setup(), and loop() running over an SDK that actually executes like an RTOS with callbacks seems counter intuitive to me.
To expand on #6, that is also why you can see I've implemented the driver more like a state machine. The original RFM69 driver has a number of blocking while loops which are dangerous to use with the ESP8266. A simple use case with a few send and receives here and there works fine, as you know. But try doing an OTA update or something with a high volume of packets and that will crash and burn. On the flip side, the ESP8266 is much faster than a Moteino, running at 80 MHz, so writing the driver in a way that 'makes sense' for the ESP8266's OS can give us a considerable performance boost.
With that said, I'll definitely consider switching over to Micropython when a stable port becomes available.