Timing in Pd can be a big deal, and to understand it, you need to know how message-rate (or control-rate, as it's often called) and audio-rate objects deal with it. This isn't exclusive to Pd, btw. It's common among pretty much all music programming, and if you ever want to write LV2, VST, AU, etc., plugins, you'll need to know this stuff, too.
In Pd (as with most music programming languages), signals are passed from object to object in what are called "blocks" or "vectors" ("vector" is more common from a math standpoint, but in Pd world "block" is the term). Objects don't pass signals sample-by-sample, rather, they pass them in groups, or "blocks", of samples. By default, it is 64 samples. An object will take a set of 64 samples, process them, and then send a 64 sample output to the next object.
Messages, on the other hand, are not bound by this. They act immediately, and the timing in Pd for these objects is really good. [metro], for example, has been known to not only be sample accurate, but sub-sample accurate.
Now, for efficiency's sake, audio-rate objects will typically take message-rate input at block boundaries, meaning that when it receives a message, it waits until the previous block is done computing to take effect. That is what [line~] does. Every message you send to it only starts at the beginning of the next block of 64 samples. Obviously, this messes with the accuracy of message-rate objects, but in most cases it isn't a noticeable problem. [vline~], on the other hand, will act in the middle of a block. When it receives a messages, say, 21 samples in, it will start it's ramp 21 samples in the next block. I emphasized that to make it clear: once a block has started computing, it can't be interrupted; therefore, sample accuracy has to be delayed by one block. But, again, this doesn't matter, because everything that needs sample accuracy will be delayed by that one block, so they will all be in time with each other.
That is all just a long way of saying that [vline~] is sample accurate and [line~] isn't
I don't know why this is, but it seems that the GUI objects in Pd only send their messages at block boundaries. So that is why they line up with [bng] but not with [metro].