This is when what makes WireGuard very performing also makes it very difficult to extend. Being in the kernel means extending it in userspace hurts its performance.
WireGuard encrypted UDP packets have obvious signature due to the packet type field in the header being in cleartext. DPI can easily filter/drop WG traffic just by checking the first few bytes of each UDP packet and doing simple statistics.
To obfuscate in this context means to morph WireGuard encrypted UDP packets to look like something else (e.g. VoIP traffic).
Current kernel-based official WireGuard implementations leave no possibility of doing so while staying in-kernel.
But OK, this doesn't cover the second need, I'm guessing what you need is down one layer, and should be done in kernel if you really think it important, but how does wg prevent you from doing that?
Build your tunnel obfuscator one layer down (I did some stateful, user-land driven, packet patching not long ago, with ebpf, it is not easy but the tooling is getting better. It seems the new way to do things nowadays anyway... And it runs in-kernel. Then lay wg above it. But having the wg codebase do what in fact the kernel should propose (pluggable transports, etc.) seems... asking the wrong team.
The Linux kernel network stack is already plenty composable without ebpf...