Yeah, not having cake sqm is the one thing that will probably kill Opnsense as a choice for some people. That’s not to say you cannot get excellent results with fq_codel, because you absolutely can (I actively use both OpenWRT and OPNSense on different network applications personally). It is definitely more work to get good results though. OPNSense’s wireguard support has been excellent for a number of years now, and it’s exclusively what I use for tunneling in a VPC I rent.
If you’re particularly constricted on host hardware and need a lightweight router to manage multiple other VMs on said host, I could definitely see the benefits of running a minimal OpenWRT over OPNSense in that case.
It does depend on the connection type, but the general rule is not completely, barring some connection types like DSL. Given it sounds like you have Fiber, DOCSIS, or similar; you likely fall under the general rule. That said, you can absolutely tune and test above the typical 10-15% safety margin many guides start with without actually incurring any noticeable bufferbloat. The 10-15% is usually a good value for ISPs that fluctuate heavily in available babdwidth to the customer, but for more consistent connections (or for those that overrate high enough that the bandwidth fluctuations sit out of range for what the customer is actually paying for), you can absolutely get much closer to your rated connection speed, if not meeting or even passing it.
The general process is to tune one value at the time (starting with the bandwidth allocations for your pipes), apply the changes, noting the previous value, and performing a bufferbloat test with Waveform’s or others’ testing tools. Optionally, (this will drastically slow down the process, but can be worth it) one should actually hammer the network with actual load for a good few hours while testing some real-world applications that are sensitive to bufferbloat. Doing this between tweaked values will help expose how stable or unstable your ISP’s connection truly is over time.