First of all, while aiming for the same "result" (display and interaction for the end user), Xorg and Wayland are very different: the first is a server, the second is a protocol.
While having been in active development for almost a decade, the introduction of Wayland to mainstream usage is pretty recent (as opposed to X, which has been used for more than 30 years), meaning that it still requires time to achieve a level of "transparent comparison".
"Themeing" is not just a matter of porting, since the appearance of an UI depends on very different aspects between those two systems. For instance, on X the client uses system mouse cursor (unless overridden), while on Wayland the cursor has to be set by the client (usually, the toolkit, Qt in this case).
Qt, being such a huge effort in cross-compatibility support, relies on a plethora of system hooks (platform plugins) that are not easy to deal with, especially in the Linux environment for which there are infinite possible configurations. Different appearance between those two is expected (at least, right now) and might be due to a multitude of aspects, many of which depend on the the window environment, installed themes and customization by the distro. It might help knowing what Linux version you're using, if you're using custom repositories, and the installed Qt and wayland versions.
With all that in mind, and especially on Linux, there's no such thing as "native window". There is an appearance that is compliant with the current window environment, but there are lots of aspects that may interfere with that, including the OS itself, and sometimes Qt can do very little with it, especially if the OS doesn't care a lot about other toolkits or uses specific customization (see Ubuntu/Gtk and the various incarnations of that distro).
Due to the deep changes some core aspects of Qt6 underwent (including Wayland support), it will probably require some more time to reach the same level of compatibility Qt5 has right now, and that also depends on how the related FOSS communities will react in the meantime. For the time being, unless you really need aspects that are only available for Qt6, if you're still beginning to study and develop with Qt, I'd suggest to stick with Qt5 for a while: it's still widely used and supported for general usage, meaning that you'll find help and resources more easily, while with Qt6 there's still room for doubts when a problem is actually caused by Qt, it's specific to a certain version or some OS/platform aspects (like it probably is in your case).
Whenever you'll want to switch to Qt6, the transition will be almost transparent and generally easier than it was between Qt4 and Qt5, with only few important changes that will require more attention (for instance, QAction has been moved to the QtGui module).
Finally, a couple of notes on your considerations about Qt and its bindings.
Qt6 is the latest stable
This is a partially wrong assumption: "stable" doesn't mean "the latest" nor "the best". The fact that a stable major version was released more recently doesn't make the latest stable release of the previous major version is "less" stable.
Qt5 has been developed and widely used for almost a decade (with many core features developed and "stabilized" years before with Qt4), which means that it is very stable, especially if compared to Qt6, that was released just one year ago, and is still going through deep development: some features have been [re]introduced and radically changed just a few months ago and it still receives dozens of bug reports a day.
It is true, though, that Qt made a questionable move a year ago deciding to limit future bugfix releases of the Qt5 branch only for commercial licensees, which raised some serious concerns since Qt6 was yet not as stable nor full-featured as Qt5 (and, while important progress has been made, still isn't). A proposal for a free fork exists, but nothing has happened yet.
That said, Qt5.15 is stable, and if you ever face a problem that was fixed in the commercial releases only it's very likely that you can work around it pretty easily anyway.
About the PyQt/PySide differences, while it's true that PySide is the "official" supported python binding, that's not the only aspect you should consider when comparing them. Besides the aspect of the license, there are some differences in how those two bindings work and their support/features: for instance, PyQt adds support for some more pythonic aspects, and notably has the uic.loadUi feature that QUiLoader cannot provide in any way.
