Rudolf and me also discussed your first point and have also the opinion that a change of the constructor of ParticleHandle is a viable way to deal with that. You would have to add the position as mandatory parameter to the constructor, that is the only property particles in Espresso have to have.
Regarding the use of Cython this is manly used to access C functionality, which can't be done in plain python. I would not know of any part where there are actually larger amounts of new functionality written in Cython. I agree with you that lots of stuff is not actually performance critical and should
be done in plain python to improve readability and ease of development (duct typing is what makes python great...).
In the larger picture Cython might not be the ideal choice for Espresso. Or at least it would be if we had a decent C++ class interface to the core, which we don't.
I think boost::python, which would be more suitable for a c++ code, was ruled out because we did not have a decent interface and people felt that they should
start with the python interface instead of giving the core a clear and modern structure first.
Also with Cython you have in principle the possibility to call Cython code from c++, which might be handy. But we do not do that at the moment and I don't see
any concrete use case for that either, but who knows....
So to summarize, we need some way to glue the parts together. As far as I can see we have almost exclusively glue code so far, which has to be Cython.
Cython was a design decision made in the past and can't be reverted easily. While Cython is here to stay, we should limit it's use to cases where it is necessary because
it interfaces with the c++ core or where it has a proven significant performance advantage over python/numpy and that part is relevant to overall performance.
From a practical point of view, I am pretty confident that people will try python first and only use Cython if that does not work or is slow. Just due to ease of development.