In the application-issued certificate approach, there is a "app" running on a smartphone or a skill running on an intelligent speaker. The app/skill is not specific to the device or device manufacturer, and can deal with many different devices.
(When it is a skill running on an intelligent speaker, there might also be a related application running on a smartphone, but that app would be specific to that intelligent speaker. The device interaction would be with the speaker)
This application interacts with the device, collecting a CSR via some protocol. The device will be issued a name by the application, with the name to IP address and trust anchor stored locally. The certification authority is a private one.
Example of such protocols would include the CSA/MATTER proposal. A more rudamentary implementation might populate the local trust store ("/etc/ssl/certs") with the trust anchor, and populate a local name mapping with the IP address ("/etc/hosts").
This mechanism does not scale easily to unmodified end points (generic desktops), but the smartphone or intelligent speaker system which owns the certification authority should be able to secure operations with the device.
Smartphones arguably have better approach commonly available to them to keep (certification authority) keys secret in a TPM or other secure element. A concern is that the smartphone is also somewhat ephemeral: subject to being reset to firmware default, destroyed/damaged by being dropped, stolen, or crushed under a bus.
The intelligent speaker implementation suffers less from the smartphone issue, being normally immobile in the home. But the intelligent speaker, by it's immobility, is difficult to bring to the device to scan QRcodes or do Bluetooth or NFC interactions. While voice interactions are potentially very powerful for day-to-day interactions with devices, the need for an administrative interface for the home owner necessitates involving some private API to an intelligent-speaker specific smartphone application.