As to why Python 3, we don't have any single hard core reason that's any different than any of the millions of "Why Python 3" blog posts that are out there. Really just because Python 2 is done (apart from bug fixes and security fixes) and Python 3 is where the focus of the Python core developers is. So far the main reason people have for *not* going to Python 3 is that they have external libraries that don't support 3 yet (though Python 3 has been around for 8 years so really by now most stuff has been updated). In our case, we don't have any libraries that don't support Python 3 (except for pypinproc which we can update).
There are a million little reasons why 3 is nicer. The proper unicode support is getting to be a bigger thing for us as people start to use MPF in non-ASCII locales. The better exception handling is what I'm personally most excited about, and the proper coroutine implementation will be nice since we use a generator for that now.
Also the 2-to-3 migration tools are great and do pretty much everything we need. From a coding standing, 2 and 3 are similar enough that this is not a big effort.
All that said, the BIG reason for us is simple:
Previously we used Pygame as our multimedia library, but now we're moving to Kivy. (A bunch of reasons for that, but that's a different story.) Also we're changing out our YAML library from PyYAML to ruamel.yaml (a bunch of reasons for that too.
.. so for the next release of MPF, we won't require Pygame and PyYAML and instead we'll require Kivy and ruamel.yaml, so MPF users will be making some supporting changes to their installs anyway.
So based on that, we decided it's sort of a "rip the band aid" kind of thing. Especially since MPF is still new (not on v1 yet) with with relatively few users. Based on the published roadmaps from the Python foundation, we know we'll have to move to Python 3 at some point, and since the move is easy and there's nothing stopping us now, we figured we'd just do it now while we're making these other foundation changes and just get it over with.
As for implementing the pinproc_read_data function, sure thing! The guy doing the updates to pypinproc (@Q-Dog in our forums) is an actual C developer, so I assume that will be simple for him, but I'll get you two in touch if he has any questions.