I think PyQt is owned by a different company, so Nothing happened to it, I guess.
PySide is waaaay more Pythonic than PyQt ever was. Types are actually translated to Python native types and APIs are way more Pythonic and not just translated 1:1 like PyQt.
You've been able to automatically translate types going back to PyQt4 (it's the default for PyQt5, wasn't changed in PyQt4 due to backwards compatibility IIRC, but you could opt-in). As mentioned elsewhere PyQt offers properties, decorators for connecting signals and slots, etc. I found the APIs to be very similar overall.
In the visual effects industry, it's common practice to write GUIs using Python and Qt that are compatible with PySide, PySide, PyQt4 and PyQt5 all at once. I think that speaks for how similar these bindings really are. Source: I maintain the most widely used shim for such occasions https://github.com/mottosso/Qt.py
That's because Qt isn't a Python library. The API is made to be compatible with the actual Qt API, so you can write label->resize(800, 600); in C++ and label.resize(800, 600) in Python.
And it's generally worth it. PyQt has been great, and I find the messaging from Pyside a little offputting -- "finally, Qt for Python." Pyside, you weren't there when I needed you, and now you're back and you want to pretend like we don't have history?
PySide didn't support Qt5. That's because the project was basically left for dead by Nokia and then Digia - for Qt proper, bindings will always be an afterthought.
Meanwhile, PyQt just chugged along just fine. Riverbank must keep focusing on it all the time or it will die. The incentives are very different.
PySide was stuck on Qt4 and basically stalled. PySide2 is practiaclly a new project. For Qt5 bindings, PyQt has been the only game in town for years, and Riverbank has done a damn good job of it.
Also, the API does not seem Pythonic at all.