My information is a little out of date, I left a company that attracted low-effort DDoSing about 3 years ago, but let me try.
> My guess is a large majority is reflective / udp or tcp zombies, with any cast edge sinkholing traffic from known heuristics or via user configured rules.
I mostly saw UDP reflection (usually chargen (!)), but sometimes WordPress reflection (thanks pingback), and occasionally old-school syn floods.
We usually would get attacked on the www servers, and they had 10G (or 2x10G), which was usually enough to just ignore the incoming traffic. For the wordpress stuff, I did add a rule to block the traffic, because they were fetching large files and I don't care about pingbacks, and don't have good feelings for WordPress, so it was catharthic to deny all requests with WordPress in the U-A. Having to wait until after the TLS handshake was unfortunate though. :(
Occasionally, something would cause real trouble with availability, but if the incoming traffic was significantly over line rate, our hosting provider would null route that IP, and our DNS would move users to other www servers; occasionally someone would come up with something that would cause issues without high volumes (ip fragments were painful without tuning[1], syn floods could be troublesome if enough volume, although going to syncookies only would mitigate that, and there were big kernel improvements at some point), I had sampled packet captures always running on the www servers, so that it would be easier to investigate than hoping to get in while the servers were having trouble. Letting the www servers fall over was acceptable as well. Somebody has a little fun at our expense, but our real service wasn't on www, so who cares?
> - are there any organisations that provide good writeups
Yeah, search for "DDoS trends" I see writeups from cloudflare, microsoft, f5, netscout, lumen (aka centurylink/Level3), sans. I'm pretty sure I read a report from Akamai once too.
> - is there any well accepted guidelines on how to ethically self-test (unsure if service providers would be happy if you kill network hops in the process)
I would get enough casual flooding (usually exactly 90 seconds worth), that I only rarely needed to self-test. But I did a couple self-tests for syn flooding, because the degree of improvement was hard to guess at without tests, and synfloods weren't super common. For that test, I tested from machines that were on the same (private) subnet, and was careful to make sure the attacked machine wouldn't transmit any responses. The point was to try not to impact equipment except the machine under test, and the generating machines.
Alternatively, most of the DDoS our actual service faced, was when we messed up something and our real clients came with large numbers of requests. No need for DDoS testing if your real load is huge. :)
> - how much real world activity leverages non-bandwidth load, such as cpu/memory consumption?
IMHO, you're only going to see that if you're getting individually targeted. It might not be too hard to find something that will consume your cpu/memory, but it's unlikely to be in a DDoS as a service toolkit, or at least not at the casual level. Often, you can turn the tables on these and only do hard work if they've established a session of some sort, and then all of a sudden, they've got to keep sessions and it's a lot more expensive for them.
[1] At that point in time, the FreeBSD kernel ip defragmentation was just a linear search through the array of fragments, with the array size limited based on the total ram available. I think there's some hashing now, but the array is probably still considerably larger than it needs to be. We did see a small amount of legitimate looking traffic with ip fragmentation, but it was tens of packets per minute; 16 fragments is more than enough storage for legitimate traffic, although with the hashing, you need a bit more. I'm not even sure the attack traffic was intentionally ip fragmented, but it was.