This raises an interesting question. Given that there's some emulation involved either way, is there a performance reason to favor the linux on bsd over the Windows on bsd approach?
FreeBSD emulating Linux has way less performance overhead than either emulating Windows.
FreeBSD's Linux "emulator" consists in a substituted syscall table and a kernel module for implementing syscalls that aren't native to FreeBSD (like epoll).[0][1]
Here's an example of what that means. When a FreeBSD binary wants to delete a file it calls the syscall unlink(2). So it's executing as a regular old binary, does a regular syscall, specifies the unlink syscall number, the kernel looks up that syscall number in that binary's (FreeBSD's) syscall table, and jumps to that code.
When you execute a Linux binary on FreeBSD you also execute it as a regular old binary except that you specify to use the Linux syscall table instead of FreeBSD's (IIRC this is done by the elf loader, so you're not even saying "linuxrun ./mybinary"; you're just saying "./mybinary"). It's executing more or less identically to a FreeBSD binary except that when it's time to delete a file it looks up the unlink system call in the Linux syscall table and jumps to that instead. Some of the arguments or calling conventions are different so most of the calls have a shim to rearrange stuff for the FreeBSD equivalents before calling into the same code the FreeBSD binaries are using. This is the same thing that FreeBSD does to support ABI versions for old versions of itself, to support SysVR4 binaries[2], and it's the same trick that SmartOS's Linux zones use as well[3]
What this means is that if your binary isn't using a lot of linuxisms, they execute at nearly identical performance.
Wine is using a pretty similar trick--trying to directly execute the binary while intercepting win32 API calls--but the impedance mismatch between posix and win32 is much higher so the cost of those shims is going to be much higher. The DeleteFile win32 API function takes a LPCTSTR that needs to be decoded, its return values have different meanings, and its semantics around files opened by other processes is different. And obviously for more complex calls the difference widens: the difference between simply speaking x11 over a socket vs calling MessageBox is much larger.
Also, Linux emulation is probably a lot easier to implement, since there is complete source code access available. Emulating the Win32/NT kernel syscalls is basically reverse engineering, which makes the progress much harder.
The linuxulator tries to be compatible with Linux 2.6.16 (released March 2006). I'm not sure about Wine but at a glance they mention 64-bit support so I'd guess at least Vista (also 2006)
That's kernel abi though. My guess is a lot of code in glibc in particular handles ENOSYS with some reasonable fallback and so you can have a newer userland.
(NB: "nopass" for doas is the equivalent of sudo's "NOPASSWD".)
Like most things relating to security, whether its use is "a bad idea" or not depends on many, many things: the attack surface, whom you are trying to defend against, other mitigations in place that protect the host, etc.
As a general rule, I'd say that yes, it is a bad idea.
However, I have an OpenBSD 5.9 laptop sitting here next to me on my desk at home:
$ cat /etc/doas.conf
permit nopass jeremy
It also has a very restrictive firewall, allows SSH connections from a very limited set of remote hosts, has only one user account that can log in via SSH, allows authentication only via keys, runs no other services that can be accessed remotely, and uses full-disk encryption. The one user account on the host has a very long, complex password that I often have to look up in 1Password when logging in or resuming.
Is it "a bad idea" to use "nopass" in this case? Strictly speaking, sure, but I'm really not too worried about it. There are a limited number of people who have physical access to it: myself, my girlfriend, friends & visitors we have over, and the few others who have a key to my house -- along with, I suppose, anyone who might break in, law enforcement armed with a warrant, and so on. I have, mentally, calculated the risk of the laptop being compromised via the use of "nopass" and deemed this risk acceptable.
On the other hand, I have OpenBSD servers in data centers and even though the physical security is very good in those facilities, I do not allow "nopass" on those machines -- primarily because they do not have some of the "mitigations" that this laptop on my desk does.
This is Linux-based, because I don't have FreeBSD experience, but is related in security posture. I have a more controversial opinion: If you're going to use `sudo`, you shouldn't use passwords.
Your login passwords should only be given to the login prompt, which you hopefully have some reasonable faith in its integrity (if not; game over already).
If you're typing your password into terminals after login, that's a great place to steal your password.
I would much prefer to use pam_krb5 to "kinit on login", and then by sudo to authenticate your session.
Then you shouldn't ever be tempted to type your password into potentially untrusted programs.
Of course, if you're sure you have no malware on your computer, then there's also no need for a sudo password -- nobody but yourself could be running commands!
Speaking from my own experience: Steam games don't perform all that well on Linux using a Haswell Intel GPU when compared to Windows. I would imagine BSD to be worse since Intel's focus is more on Linux, and the Intel BSD driver tends to be a version or two behind. On the other hand, the proprietary Nvidia driver for BSD is fast and stable, in some cases faster than its Linux equivalent, and Nvidia seems interested in continually improving its driver for all platforms simultaneously.
The situation with Intel GPUs is improving though. There's ongoing work to make sure that Linux graphics drivers can be used on FreeBSD where no native driver exists yet. Also, there's a good chance the work in Dragonfly BSD will make it into FreeBSD: Dragonfly has pretty decent support of the more recent Intel chipsets.
Steam on PC-BSD - How to Get Wine Running 3D Games: https://www.youtube.com/watch?v=B04EuZ9hpAI
Steam on PCBSD 2 - Using Wine as a Streaming Client: https://www.youtube.com/watch?v=BJ88B8aWdk0