I should have put this in the month of WTH when I had the chance 
We have areas(), labels(), floors() but no support for devices() while templating. Having such an extension would allow for broader querying beyond the area_devices() and label_devices(). If simply wanted to display the total number of devices on a dashboard, I can’t easily do that today.
Proposal: add a devices() extension to the templating engine which returns a list of device_ids.
Devices are just a bunch of entities grouped together and one of them is chosen, by the integration for it, as the state for the main device.
Devices should be avoided.
Use entities instead.
IDK if I agree with/understand “Devices should be avoided”. As you explain, devices are a grouping mechanism much like areas, floors, or labels; each of those have a template extension (areas(), floors(), labels()) so why not devices? If there is a technical reason users should avoid using devices in templates, that is fair but I haven’t come across any documentation which calls that out.
Without my proposal for devices() the most succinct way I can think of to query for all devices (some devices may not be associated with an area so querying by area_devices() is a no go) is:
states | map(attribute='entity_id') | map('device_id') | unique | reject('eq', None) | list
Beside many entities not belonging to a device, so your query would be incomplete, then there is this:
The linked topic makes sense; thanks for sharing. That bit of guidance would be a great addition to the official docs site.
I made the request because I defined a macro in a custom template with the code above to my needs in the context of a dashboard. I can see that in the context of a script or automation, the addition of a devices() extension would be of limited utility.
The experienced users of the forum try to make that thread as public as possible.
It seems pretty hard to guess what the devs actually want to do with devices and it has been like that for a long time.
We are a bit of in a limbo.