Yup, that's exactly what it does. So this relies on the traffic having a DSCP marks set when they enter the wireguard interface.
Well, if qosify runs on the physical WAN interface, it'll look at the packets as they appear there, which means all wireguard traffic will just be identical encrypted packets. It should be possible to run both qosify and preserve-dscp, though; either by making sure preserve-dscp runs first (on the physical interface) and that qosify leaves existing DSCP marks alone, or by running preserve-dscp last and having it overwrite any marks set by qosify. I don't know to what extent this will require modification of either.
As for setting the marks on the traffic inside the wireguard tunnel, the qosify BPF classifier could run on the wg interface as well setting the marks there (but it shouldn't install a cake instance on the wg interface, obviously).
This has been proposed multiple times, and I wouldn't hold my breath. Preserving DSCP marks is an information leak and Jason (the wg maintainer) is rather opinionated about not doing that 
The smoothest thing would probably be to teach qosify about "inner interfaces" and incorporate the skb->hash lookup logic of preserve-dscp into the qosify BPF program itself. Should be fairly straight-forward to do, I would expect.
Basically, you'd add an inner_interfaces config parameter to qosify, which would cause the classifier BPF program to be loaded onto those interfaces, but instead of setting the DSCP mark directly in the packet, it would store the DSCP value in a map keyed on skb->hash. And then amend the BPF program running on the outer interface to first lookup the hash in the storage map and read the DSCP mark from there, and if nothing is found, do the regular classification (which would then apply to anything not in the wg tunnel).