although I cannot follow that (0,0) argument, for a Transform3D always describes a position relative to the parent. So it always counts from (0,0) of its reference frame.
Virtially, a 'true' (0,0) never exists.
There is a very real and distinct mathmatical difference between a directional vector and a positional vector.
Lets put it in example terms:
(1, 1) -> (7, 9)
That means: move from (0,0) by (1,1), then move by (7, 9) ending up in (8,10). Now the (1,1) does describe a Point since the parent of (1,1) is (0,0), but the (7,9) describes a directional move from (1,1) hence the (7,9) is not a point, but a directional vector.
The Transform3D#set(...); cannot be a Point since a Transform3D can have parent transforms which would clash with the idea of a Point, but the idea of a mutable vector that can be both a positional vector and a directional vector works, hence Vectors is an elegant solution to the problem.
Since I am familiar with your gameobject API, I would go for Movable#set(Point3f, Quat4f). This is because the Movable object has no inherit transformation stacks and thus, only requires the final result of the transformation which is a Point, not a Vector. In essence, your Movable object requires a "world view" and not a "local view". Hope that makes sense, if not, ask away and i'll try to explain myself more.
As a side note, I think the whole idea of having Point, Vector and Tuple in a math API is stupid since conversion from one form to another is necessary for performance. In your example a Movable could describe the Transform of a leaf node which is the result of the accumulation of all the transforms into 1 Point, but you can't cast a Vector to a Point since Point doesn't inherit from Vector. Simple documentation could be written on each method to specify what that method takes, whether it was a directional vector would suffice. Hence why im very reluctant to move to vecmath for VE.