I don’t believe Frenck’s post, that you quoted above, is about entities created by the Template, MQTT, REST, etc integrations. All of those official integrations allow the user to decide, based on their intended application, whether to employ attributes or not.
The advantage the attributes
property has over an entity’s state
property is that it’s not limited to just a 255-character string; it’s a dictionary whose values can contain other data types with no size limitation (other than the host’s hardware limits).
The comment by Frenck that does apply is the one he posted above:
A read only input helper would be a sensor… not an input.
Based on that opinion, CentralCommand and TheFes offered straightforward ways of employing a Trigger-based Template Sensor whose value can be easily set by a service call, just like for an Input helper. CentralCommand’s example offers the additional advantage of supporting device_class
and unit_of_measurement
so the value’s appearance in the UI can be influenced (not possible with Input helpers).