Perhaps, but the pfSense community has gotten toxic over the past few years, mostly due to the commercial side and the very aggressive stance towards any perceived loss of income.
Projects like pfSense, OpnSense and other GUI-on-top-of-OS systems are only sensible for more end-user applications and community driven approaches. I switched from pfSense to OpnSense not because of any real diffrence between the two, but because of the backing community, which is more for the users than it is for me personally; most people using this stuff are in the home of SMB markets and are much more serviced by a Web UI and a community than some commercial entity.
Once you go commercial or deep technical, none of the projects make sense as you are almost always better of going current with a configuration management based system (like plain pf on a BSD in combination with something like SaltStack, Ansible, or Chef) or go classic with one of the larger vendors like Cisco and Juniper.
pfSense is shooting itself in the foot by being (petty) d.cks, OpnSense is shooting itself in the foot by (and this is hearsay afaik) technical deficiencies in the primary backing team. On top of that, prosumer vendors are now getting the hang of it and are releasing affordable, supported, yet not too-expensive hardware for most of the setups you'd see those BSD-based WebUIs in. (i.e. UBNT)
I'm predicting that pfSense will try very hard to go full-on commercial, perhaps using the open core model like GitLab does, but probably failing at the commercial side because the advantages (that that goes for OpnSense too) vs. a prosumer/entry-level device from an existing brand are getting smaller and smaller. Most of the advertised stuff (again, goes for both) that you'd get for using open source software isn't really that much of an advantage anyway, most users never report bugs, write patches, inspect the OS, or check checksums. For OpnSense, they are probably going to try to not make a split product, but instead try the vendor network model where you make money by selling support and perhaps pre-configured hardware for people that are stuck between prosumer and home gear needs.
What I personally would like (and I'm still using a mix of pfSense and OpnSense for all GUI-needing systems) is an API-first system, with either no GUI at all, or an optional GUI. Maybe in the direction of VyOS (https://vyos.io/), which is linux based, and currently API-only. This would perhaps have to compete with OpenWRT, but at that point we're getting pretty far away from the capabilities of BSD.
A lot of the setups where there was no budget, or the firewall/router had to be virtual are currently only running pfSense/OPNSense because of a lack of better alternatives, the paid systems are not 'better' by any means, and their past USP was always with the hardware (which at some point became obsolete as well as packet processing in software became fast enough).
For now, I'd suggest anyone who needs a software router/firewall/gateway with a GUI and reasonable OS to first check OPNSense, as for most uses a healthy community is important. For everyone else, it's probably not really an issue in the case of cloud networking as they all have API-driven (and a GUI to drive the API) firewalling which covers almost all SMB use cases. So far I've only seen three cases where the box-with-a-firewal-and-GUI approach still matters: home, smb, on-prem with no investment in skill. As soon as you have the skill and infrastructure to go without a GUI, none of the sense/ wrt and prosumer systems matter, and as soon as you go beyond the 'need to buy stuff because we don't know or want to do it' stage you get in MSP/Cloud territory.
Editing (mostly for my own update regarding what's out there) for some extra projects:
There seems to be a number of 'other' projects in various states of integration, support and maintenance;
1. https://bsdrp.net which looks like a much more 'embedded' CLI router, has configuration abstraction
2. https://securityrouter.org which uses open everything except the nice backend which does paid upgrades for features
3. Floodlight Controller has a REST API for configuration, which does mostly firewalling and switching, not really a gateway or something like that, lives mostly in the SDN realm, mostly found on Linux systems instead of BSD, but it's a model that comes closer and closer to the model you get on providers like AWS. CloudFirewall is an (older) example of letting one device do the packet and frame forwarding, but some other service do the rules and control of one or more of those devices (be it hardware or software devices).