[1] If the device is not sending diagnostic data, there is still an alternate path for Secure Boot certificates to be applied. Devices can be included in the High Confidence database that is delivered with cumulative updates. When a device is identified as High Confidence, the Secure Boot certificates are applied automatically.

For client devices, there is a relatively high likelihood of being classified as High Confidence. This is much less likely for server and IoT devices.

[2] Yes. Automatic application occurs for devices that are determined to be High Confidence based on data from other similar devices.

[2.1] The default Secure Boot behavior will automatically apply certificates for High Confidence devices. Leaving Automatic Certificate Deployment via Updates set to Not Configured or Disabled allows this path to function. Unless there is a strong reason to avoid relying on this mechanism, it is generally recommended.

As you noted, Certificate Deployment via Controlled Feature Rollout must be Enabled, and Required diagnostic data must be sent for this option to work. This can be more difficult for some IT organizations, either due to data‑sharing policies or challenges ensuring diagnostic data reaches Microsoft.

[3] Yes. Enabling Enable Secure Boot Certificate Deployment bypasses the need to send diagnostic data. This explicitly instructs the device to apply the Secure Boot certificates and the 2023‑signed boot manager. This option is appropriate when you have confidence that the device firmware can successfully process the update.

[4] Yes, that is correct.

Additional note on firmware updates
Firmware updates are not required in most cases. They are primarily needed when there is a firmware defect that prevents Secure Boot certificates from being updated, or when you want the new certificates present in the firmware default variables. The default variables are used to initialize the active Secure Boot variables.

I hope I've answered your questions.