Sure, the thing about decompilation is it's by nature taking lossy data and trying to turn it into something that is almost lossless. The working theory of most decompilers, including Ghidra's, is to have a base level of "translation" ability between asm and C (for example). However, there's a ton of stuff that is missed in this base level. Every compiler speaks it's own dialect of assembly, and different compilers prefer different optimizations, code removal, etc as a strategy. As a result a good decompiler also includes heuristics that are expensive to create and learn about. Hex Rays has dedicated an entire company to finding these heuristics in many compilers across many platforms. This isn't knowledge that is easy to acquire or maintain. I think that Ghidra has the right sauce to do it (a large community) but it will be a while before that community can organically produce the same results.

Due to these heuristics IDA produces real actionable code quicker. My experience with Ghidra (less than yours) is that it produces mostly garbage on a lot of different things and it requires a lot of prep work to make truly usable. This might not be noticeable on small or simple binaries but on larger binaries it actually becomes a real measurable problem. While Hex Rays isn't perfect, it's about as close as we can come to it right now and it generates very human-looking code with smart optimization removal. One thing I remember with Ghidra not long ago was a common optimization like using SSE registers for arrays would produce a page worth of non-sense for something simple. Additionally, detection of standard libraries still isn't good so you end up wasting your reversing time on re-reversing a different compilers version of strlen than actually doing the work you need to do. If you could use FLIRT signatures in Ghidra legally I'd imagine Ghidra would be vastly improved.