This isn’t going to be specifically about OpenBSD, because without taking Linux in comparison, you’ll miss details on how things have turned out to be. I have been spending some time lately following what the situation is on the BSD front and in the Linux community, and I apologise in advance if I happen to be incorrect about this somewhere (especially regarding the *BSDs, since I’m more of a Linux guy).
OpenBSD probably supports more cards than FreeBSD when it comes to laptops, but always good to ask before you buy a machine to put it on. Thinkpads have been ok from what I heard.
We’ll look at a few more things though that you may want to consider.
The BSD people usually prefer permissive, copyfree licensing for their operating system and tooling developed natively for the platform (for historical, philosophical, and corporate interests), this means less headache for developers (really), not having to deal with lawyers everytime someone violates your license, and you’re allowing anyone to take away your code without really (they still can) having to give you back (which is kind of a tradeoff if this bit really matters to you).
Linux otoh and all of GNU are licensed under a strict copyleft license, the GPL and things less severe (like the LGPL which allows libraries to be linked against proprietary software) and so on. The kernel has an entire foundation backing it and working to enforce their license terms throughout Linux’s use anywhere in the world, which ofcourse is not a problem for developers but still has a lot of energy consumed (and we saw with grsec that you still really can’t do much). There are also software foundations and companies developing for Linux using a range of licenses as they see fit for themselves.
The key difference here (wrt licensing) is that if you really want a solid well-maintained system with permissive but homogenous licensing, BSD is a better choice (which is the case for companies wanting to ship closed source software as their products, not a bad thing however), BSD is a better choice, but if you really don’t care as an end user and just want to at best avoid a certain license when you can, Linux distributions will work for you. Linux is just about mixing and matchinf things to suit yourself, distributions do the work, but unlike BSDs, you have choices from glibc to musl up to every core component. (You do hace choices when you use openbsd’s bionic libc instead of freebsd’s libc, but you dont really have a choice with just freebsd, not to say this isnt possible, just not enough people wanting that).
The userspace is also a lot different, long options go away, options become different, common utilities behave differently than you’d expect them to (most of the time it is just GNUisms), and the ecosystem is all in all very different. cvs and svn are a lot more common than git for development, and package distribution, while it may appear similar on the first sight, is a lot more comrephensive. Use binaries as you wish, or build from ports when you desire (which is also what you get on arch but ports use standard Makefiles instead, and nothing homegrown). Administration utilities are well documented and orchestrated. One key difference is that boot is still rc based, so you may need to adapt systemd services when migrating.
Security: This is where my main point on OpenBSD’s security promises comes in. The whole thing is a bit oversold, but you only realise this when you buy into it. The base system is heavily audited, audited in cycles, and audited and audited and audited…so much that there have been just 2 remotely exploitable security holes thus far in the project’s lifetime. However, unless a certain port is patched to meet atleast some of the QA standards of the project, the security promises are just nullified. Only things in base actively use pledge, W^X and so on. The focus is more on vertical security, something I will outline later; which is kind of a setback imo, but it really is a choice between complexity and features. Things aren’t that bad though, X and most of the stuff you would use daily would be covered so if you don’t really need too many applications, things are going to be just fine (base has Xenocara, a wm, vmm, vi and mg, httpd, pf, and so on). pf is a great attraction to some, and it is in base.
OpenBSD has a lot of security features otoh, so the base system is really solid, well audited, and consistent. From the point the bootloader picks up, to the point where your system becomes usable, there are many things in play to harden the system (something to make the kernel loading in memory random was in works, apart from the well known pledge() and other stuff).
FreeBSD also employs less but a fair share of practices to secure the system, from using jails for running system services and almost anything (think of it like containers) to using capsicum for syscall filtration, and things like dtrace that help in observability, and ZFS (obligatory).
Anyway, I wanted to cover Linux mainly, where things are really different. Linux has numerous security frameworks and subsystems, and focuses equally on horizontal and vertical security. What are they? Horizontal security is is the principle of least priviledge, things like sandboxing by giving the process an alternate view of the system through namespacing so as to prevent it from being able to interact with anything more than it needs to, while still running is as say root. Linux probably does this pretty well, mostly because the technology used is broken into pieces and not first class unlike jails in freebsd which have a strong notion of just namespacing or chrooting, you can mix and match pid namespaces, mount namespaces, resource control, scheduling policies, and so on (can also be done in freebsd ofcourse). Things like docker, systemd, and many other projects already leverage this functionality from the kernel. Things are transparent, and there’s nothing like a container like there is a jail, its just a set of namespacing attributes applied to a process or a set of processes (which is kind of a problem when you want containers to be distinguishable through IDs to map data in a store for them, which can be worked around ofcourse by putting this abstraction responsibility in things like docker or systemd which expose containers as first class objects, but then it only applies to userspace, the kernel has no idea what a container is).
Vertical security is about not allowing this process to break of its allowed priviledges. Vertical also because it must now rise through the ranks and achieve higher capabilties by breaking out.
Tradeoff: BSDs focus comparatively less on horizontal security (esp. OpenBSD since you asked) because horizontal security comes with a big tradeoff: complexity. More code, more stuff to audit, and a very complex security model where it is not easy to tell what priviledges a process has (which is why something like systemd exposes stuff like this over D-Bus, by making the service an object in the execution engine which is introspectable). The simple answer without getting into details is vertical security is simpler, and horizontal security is complex, more code makes them system vertically less secure but it is needed infact in order to implement mechanisms for horizontal security. Linux has seccomp, SELinux, AppArmor, Capabilties, and so many other things to implement this, apart from aformentioned namespaces. OpenBSD wants its security model to remain stronger vertically and simpler to understand, while Linux has everything you need to span in all directions as you need to. OpenBSD however leaves no part untouched when it comes to security, so in those terms common GNU/Linux distributions like Arch are less than fit to be compared unless you use patchsets to also harden userspace and the kernel further.