Not posted as a bug because there might be a good reason for it, although I can't for the life of me think of one. Compare and contrast the return types for these IScenNode methods:
'const core::vector3df &' seems like the most intuitive type to me, but I'd have expected them all to be consistent, rather than returning three different types.
Hmm, getScale and getPosition are possible with const&, but getAbsolutePosition is not. Seem like some methods went through when I searched for const candidates.
Because it would return a reference to an object on the stack? Hmm, actually, returning const& for the others might produce unexpected results if the caller hangs on the reference until the value of the referenced variable changes.
There probably isn't a right way to do it, but some consistency might prevent other people bugging you with this question.
It's also a pretty important thing with ISceneNode, because many people create custom scene nodes and might bother with the interface methods signature. So now they have to look up each interface method and check if it's const& or just copy. That's why a uniform way is also very comfortable, it just shouldn't have an impact on the performance.