While the lack of full rate 256-wide operations was quite noticeable, I was expecting it- the cliff that caught me by surprise was something else: certain kinds of inter-CCX communication seem to be catastrophic for performance. The rest of this is partially speculation since I haven't had time to dig deeply into the problem.
Specifically, in both a physics engine solver and some machine learning backwards passes I was working on, there are areas where a little false sharing is likely. It's relatively uncommon and a negligible concern on the smaller Intel chips I tested on, but Zen cores will sometimes have to synchronize with another CCX's caches and it seems to come with a penalty vastly larger than naively expected latency or IF bandwidth.
A fully loaded 2950x ended up getting beat by a 1700x in the solver despite having virtually the same architecture, twice the memory bandwidth, and an observed clocks advantage. Cutting the used thread count down to the same as the 1700x helped a little, but it looked like Windows was scheduling the threads on as many CCXs as possible and it ended up still being slower.
On the upside, the 2950x blasts through friendlier workloads like collision detection and inference with perfectly reasonable scaling.
I'm hoping that the dramatic redesign in Zen 2's memory architecture (unified IO die and whatnot) will help things a little. If not, I'll probably have to rework some stuff.