It probably does seem a bit of a faff, although once you are geared up to use the CLI it is a five minute job if there aren’t any custom attributes or commands around.
The above is a real example with a different use case.
The flow for ‘new’ integrations is to create a device profile, first defining a device type that leads to the icon used for the device, adding capabilities, then specifying which ones to use for the status and action on the dashboard tile. So that rather makes sense. This process is itself evolving, particularly in terminology, to better match the steps used with the CLI.
The Groovy device handlers are still based on the legacy architecture and so have to be retrofitted with support for the new UI. It isn’t pretty, but then I do wonder why the legacy UI was embedded in the device handler in the first place.