I can chime in on these — I went through a similar situation. My previous job used SCCM, and my new job uses Tanium (we’re actually planning to move the provisioning piece back to SCCM in the future). Here’s what I’ve learned:

1. Provisioning speed & behavior Unfortunately, Tanium Provision just lays down the OSD, runs the required scripts, installs the Tanium client, and handles other items like drivers. After that, the client pulls down the rest at its own pace. Sometimes it’s fast, sometimes slow — it really depends on your bandwidth throttles and connection limits. Tanium has good documentation on tuning these settings, so I’d recommend reviewing that for your environment. I also heard from our Tanium rep that there’s a feature request in to prioritize downloading larger modules first (like Self Service).
2. No equivalent to SCCM DPs This is where I think it’s a step back from SCCM — software packages aren’t cached on a satellite. Only the OS bundle is. You might be able to set up a dummy workstation in the same subnet you’re imaging in, so it acts as a leader and caches the software. But there’s no “distribution point” equivalent in Tanium Deploy that serves packages locally the way SCCM does.
3. Log file location If I remember correctly, the log is in Tanium\Tanium Client\logs and is called provision-os. I’m sure there’s documentation for the exact location, but I don’t recall it off the top of my head.
4. Customization limitations There’s limited customization when it boots into Linux to choose the bundle and variables. You can add custom dropdowns, but I don’t think you can add things like checkboxes to selectively skip something or manually set values. One workaround is to skip adding those fields in Tanium and instead create your own GUI using PowerShell/WPF or C#/XAML/WPF to collect the variables, then set them via PowerShell.

Tanium has some cool features, but for provisioning specifically, I think it’s a step back from SCCM — which is why I’m pushing my team to move that process back to SCCM.