To be clear, my strong preference would be to add tactile paving information to the barrier=kerb node and nowhere else. However, the most popular editor for contributing tactile paving information is StreetComplete, which is unfortunately unable to create new nodes or edit nodes other than the one that turned up in a query.
Additionally, we need to somehow accommodate crossings that haven’t been mapped as ways yet. While it may seem like a contrived scenario to have tactile paving information without the full crossing geometry, this can definitely happen when local mappers aren’t on board with separately mapped sidewalks, or the crossing isn’t visible in aerial imagery, or the crossing is for a pedestrian lane that isn’t physically separate from the roadway – and then a StreetComplete user comes along and contributes tactile paving information. Even in my area, where I tend to map crossings as ways and curb ramps as separate nodes, I still see StreetComplete users come by and contribute (usually consistent) tactile paving information on the highway=crossing nodes.
I hope that, someday, we can deprecate the redundant mapping of a node and a way at the same crossing. Until then, a tag on the highway=crossing node would make more sense for backwards compatibility than the highway=footway footway=crossing way, because the highway=crossing node itself is a concession to routers and renderers that aren’t sophisticated enough to handle crossing ways. Some tags on the highway=crossing node should match the highway=footway footway=crossing way while others should match the barrier=kerb nodes. Communicating this distinction is difficult, so I wonder if editors other than StreetComplete should stop offering tactile_paving as a discoverable option on anything other than barrier=kerb.