boost removal is an ongoing, low noise effort.
At this point, if you build without python, you can build the usd libraries treating boost as header only, without actually building boost. one or two of the command line tools use boost for command line options.
Porting those to (my suggestion) CLI11 would remove the last non-python boost dependency.
to be redundant and clear: you can manually cherrypick the boost headers into a quarantined folder, and build usd against that, as long as you skip the python integration, and whichever command line tool still uses it for command line parsing.
a priority, in my opinion, would be to remove boost inclusion from public headers in USD, so that the dependency doesn't leak out.
The Work library could encapsulate tbb in order to prevent the tbb headers from leaking out. Removing tbb would be much more difficult though, because it is providing some functionality not provided by std.
PRs favoring std over tbb would have a better chance if accompanied by benchmarking that shows no regression, or better, an improvement
a priority, in my opinion, would be to remove tbb from public headers.
tbb shouldn't cause the kind of contention that people worry about, because usd isn't sitting there consuming cores in the background. tbb only lights up during loading, scene composition, bounding box computation, and other things that in principle should be intermittent, not constant.
tbb compiles and runs fine on ARM, despite what you'd expect.
tinyusd for all intents and purposes, attempts to identify a gltf-like subset of usd that is parsable minus composition. It will always, by its nature of emulating another system, be in a position of chasing a large moving target. It's unclear to me if it offers a benefit over gltf in practice, unless for a need to use a usd subset on a platform too small to host the USD libraries.
in order to pull off a full static build, tbb needs to be build appropriately. For myself, I wrote a different CMakefile.txt for tbb. It is a fully trivial, just the necessary cpp files and preprocessor definitions, which didn't take long to reverse engineer. This is fine if you are not intending for your embedding to globally cooperate with other systems running tbb. For my case, which is usd running in a real-time game-engine-like system, on a performance-dedicated machine, that's absolutely the case. If you have a hard requirement that Houdini and your engine run simultaneously at top performance you'll get over-subscription (your engine or Houdini framerate will suffer), intermittently, when USD does something heavy. A solution there is to tell USD to use a small number of threads. YMMV.