There is no easy solution.

The created Line2D is a generic independent object, which doesn't know about the "single y-value" property of a horizontal line.
Not allowing scalar values makes sense there.

Options are:

1. Accept scalar values in Line2D - we decided explicitly against this in Enforce that Line data modifications are sequences #22329.
2. Create a (sub?)class HorizontalLine2D - This would go into the direction of semantic Artists, which we are basically open for. But I'm not convinced it makes sense to have an individual Artist for every function.
3. Make the behavior of Line2D configurable, easiest through a simple Line2D._allow_scalar_y that axvline would overwrite. But this is either quite hacky because do is silently (i.e. also the set_ydata documentation would not reflect it), or we'd have to promote it to a regular feature, which does not really make sense for Line2D and adds complexity.
4. Do nothing and live with the surprise and inconvenience that you have to pass two values.

My preference is (4) > (2) > (1) > (3)

Edit: There is one more way that's in a sense even hackier than (3) but may limit unintended fallout. If a scalar is passed: Check if all existing values are the same, and if so, replace the values. 🤯

I came across this because I'd had code that was working for a long time (axvline + axhline), and suddenly set_ydata/set_xdata failed, without a visible deprecation warning. I fixed the code in my project, and because we make regular releases it'll limit the fallout. Perhaps a documentation fix will be enough?