This discussion is already a bit old, but I would still like to chime in:

In my opinion, pymeasure (or at least parts of it) is a good choice for a research lab:

• It requires minimal effort to use existing instrument drivers, and quite little effort to implement new ones - the entry threshold for the driver library is small.
• It is kept in pure python, so students do not need to learn a host of programming languages to work with it, but a single one, which is very popular in a range of fields
• The development is ongoing, just as research is. pymeasure (as I see it) has been primarily maintained by PhD students who work with it in their labs, as well as some people in the private industry, where the company (apparently) thankfully decided that some of the time of the employees may go to Open Source projects. Being "in development" in this case (I think) is a good thing, as it demonstrates being maintained, and improved according to the needs of the research labs. We just don't come around to say "this is now the completed version Y.X" very often.
• By using pymeasure, and having students contributing to it, you can have students learn and teach python, and you do not have to rely of a homebrew solution of a single student, which might be way less maintainable than this collaborative effort. By allowing students to contribute (and possibly help in the maintenance), you can effectively contribute to keeping pymeasure alive, as you put it. This will also help students in their future career, as they learn how Open Source software collaboration can work.
• In most research groups, a small number of personnel does much of the software development workload - by collaborating with other such (almost) individuals in other groups, all of them gain a lot, and the whole research lab may benefit from the knowledge of other groups' members, collaboration at its best
• LECO is very promising as an overall communication standard, and pyleco will allow for simple integration of pymeasure instrument drivers with a bigger data acquisition system, as was described above for pymodaq. By learning basics of instrument control through using pymeasure, students may have a good start into the topic.
• We have quite motivated maintainers: you will notice, that although there are quite a few Pull Requests open, this is not due to a lack of interaction (and thus non-merging) from the side of the maintainers, but because they diligently review the valuable contributions, and often there are a number of points to address before merging.
• Compared to PyMoDAQ, pymeasure is a little smaller, both in possibilities and the entry threshold. If you aim for a synchrotron facility, pymeasure is not quite the tool for you. If you aim for a lab of a few rooms, with a number of different individual setups, a tool like PyMoDAQ (and other synchrotron-level tools) will be overkill, and pymeasure/pyleco might be a good point to start.

In turn, research labs can contribute a lot to science in general, by using and contributing to pymeasure (or similar packages), and consequently promoting a collaborative way of conducting scientific research. There is an incredible amount of competition and (hidden) hostility in science (in some fields more than in others), so some collaboration on points which are unrelated to research topics in themselves, are surely helpful to science.
Some of the arguments which I here put forth will apply to a number of different python data acquisition packages as well - however, in my experience, without personnel which is fully dedicated to research software engineering, a low entry threshold is very important, and pymeasure does a good job on this point.

In conclusion, all the best for the new lab :)