For many of the kernel tracing tools, I'll add user stack traces as needed for the user context. TCP connections and latency _with_ the Java code paths responsible; ditto for disk I/O, memory growth, lock contention, etc. If you've ever had a network problem, a disk I/O problem, a memory problem, etc, BPF can give you new insights that are unavailable from user-space tooling.
But that's also why BPF doesn't seem to have a place in this world. Anything surfaced by a BPF program should probably be surfaced by a proper kernel module or syscall. As far as I can tell, the utility of BPF tracing is solely between the time a bug comes up, and a few weeks later when a kernel upgrade exposes this info anyways.
Neither of your suggestions really get at the point of eBPF. That is, to safely (goodbye kernel modules) and dynamically (goodbye syscalls) instrument the kernel.
For many of the kernel tracing tools, I'll add user stack traces as needed for the user context. TCP connections and latency _with_ the Java code paths responsible; ditto for disk I/O, memory growth, lock contention, etc. If you've ever had a network problem, a disk I/O problem, a memory problem, etc, BPF can give you new insights that are unavailable from user-space tooling.