The bug

This results in vines with either a full block's hitbox (1.12.2) or no hitbox (1.13-pre), but visually they look like they're set to south. These vines are also mostly unaffected by randomTickSpeed and thus will never decay/grow. An exception to this is if you setblock the vine next to any block(s) that it's able to attach to, in which case it'll automatically update its blockstate to match a nearby block upon being randomly ticked (note that updating the block itself by placing other blocks will break an all-false vine; it has to be updated by a random tick). All-false vines can still be climbed though.

Probably related to MC-85967, which was seemingly very questionably marked as WAI for the simple reason of "because you can't climb them without a block behind it", despite that statement being technically untrue even back then (there just needs to be a solid wall within climbing range). This might technically be a dupe of that report, but I figured this one has a bit more info in the title/description, as well as behaving slightly differently across versions (what happens in the other report's version seems to match 1.13-pre, while 1.12.2's bugged vines actually have a hitbox).

Either way, this clearly seems like a bug, not WAI. South-facing vines seem to be the intended default judging by the visuals. If all-false is WAI, then for example why aren't cobblestone walls the same? Their "up" value is true by default when running these commands, whereas going by how it works with vines, you'd expect it to be false. Not to mention block updates destroy all-false vines, even if it you place an attachable block on the visually correct side (which is kind of a minor and moot point anyway admittedly, since I don't think all-false vines can spawn naturally).

How to reproduce

1. /setblock ~ ~ ~ vine
   

2. Look at the vine
   It has no hitbox