I'm currently in the middle of a bulk build waiting for
devel/cmake-core to complete and wondering whether It's a mistake to have hyperthreading. I suspect without that a single package on which other builds are waiting might go twice as fast. Hyperthreading might be great for everyday use but for compiling, I wonder whether it's slowing things down as dependencies mean there's a limit to what can be done in parallel and it might be better to have more speed on fewer cores.
What do people think?
Disclaimer: This broadly speaking but you get the idea.
How the port actually builds
For example:
* Ports utilizing GNU Autotools (and/or gmake) are in general notoriously slow/processing heavy and have very limited multithreaded. (We have a lot of legacy / old ones in tree)
The ./configure process is always single-threaded and slow, (g)make is relatively smart but do have some limitations when it comes to multiple subdirs however it works pretty good in general.
* CMake and Meson based ports are in general much faster, both during "configure" stage and much better at utilizing cores during builds especially on systems with many slow cores.
This is one of many reason why I have my little overlay repo

* Rust ports are multi-threaded by default, however linking process is single threaded (for performance / size reasons) but can be very compute intensive and memory hungry
I would go out as far as and say that you gain more by allowing more jobs ("threads") per port rather than building more ports in parallel with fewer jobs.
This is a tradeoff and you likely will run out of RAM sooner than CPU power.
On a Ryzen 7900 the following is a pretty good balance in general,
Code:
PARALLEL_JOBS=6
MAKE_JOBS_NUMBER_LIMIT=8
This leaves you with up to 6 ports being built in parallel and each using up to 8 "threads" which is pretty much a sweet-spot with 128Gb RAM and tmpfs despite having only 24 "cores".
Poudriere cannot take into account in scheduling if a ports only uses a single thread for the complete build or if the build process is on the linking process so all builds are being treated as equal. This overbooking of capacity turns out pretty well given that you have bunch of build stages where not all cores or each port are being utilized. If you have slower cores you'll likely benefit more by allocating more cores per port rather than build more ports in parallel due to dependency chains. At the same time you have to take into account the amount of RAM you have available, a good rule of thumb (in general) is about 1Gbyte / core because you want to avoid runnnig out of RAM and/or excessive swapping.
Disabling multi-threading in general rarely makes up for it.