That can work, but it can be accelerated by using a Space.RayCast.
The RayCast queries the broad phase acceleration structure (Space.BroadPhase.QueryAccelerator) to find intersected bounding boxes. It then goes through the BroadPhaseEntry objects it detected from the broad phase and performs a narrow ray cast against them (if they are accepted by the RayCast filter, if one is specified). Since it only tests objects identiifed by the query accelerator, this is very fast.
There are multiple overloads of the Space.RayCast function. Some return multiple hits, some return the first hit. Some have a filter. Some have a maximum length, others have implicitly infinite length.
The ray cast returns whether or not the ray hit anything. It also has has parameters which output the hit data. This includes location, normal, T value (distance along the ray in terms of the ray direction's length), and the BroadPhaseEntry object which was hit.
StaticMeshes, Terrains, InstancedMeshes, and EntityCollidables all inherit from BroadPhaseEntry and live in the BroadPhase. So, the ray cast can hit them. Since your goal is to pick an object up, you're looking for entities. If the BroadPhaseEntry found by the ray cast is an EntityCollidable, cast it and check the EntityCollidable's Entity property to find the entity.
You can also use tags to do this. The BroadPhaseEntry has a Tag property which is separate from the Entity Tag property. Instead of doing the cast first, you could check the BroadPhaseEntry's Tag to see if it's a pickupable object before attempting to find the entity. Since the entity.CollisionInformation property returns the EntityCollidable associated with the entity, the entity.CollisionInformation.Tag is what would need to be set for this purpose.
When I'm holding an entity in front of me, and rotate the camera with a mouse, the entity follows correctly, but its movement is a little "buggy" and not smooth at all.
It's weird because when I "move" with keyboard keys, the entity follows very nicely and smoothly.
I'd guess this is a byproduct of the particular way the velocity is being controlled.
First, it's being teleported. This is a dangerous operation as an object which is teleported can teleport into things without resistance. Only the post-overlap penetration resolution system will fight back, and it's not rigid. It can work, but the less physical interaction between a teleporting object and its environment, the better. It might be good to set the collision rule of the box such that it cannot collide while held to avoid this (though then you must handle the case where the object can be effortlessly stuck through walls still, to stop players from just tossing objects into the void or whatever else). This is probably not at fault for the unsmoothness, but it is something to be aware of.
Second, the velocity does not match the motion of the character. The linear velocity is always shooting directly forwards despite it being held with teleportation. A held object should have a velocity matching its position relative to the character. That is, if the character isn't turning, the held object's linear velocity should be the character's linear velocity. If the character is turning, then there will be a secondary component to the velocity from the angular motion. Determining the position goal and then computing the exact velocity needed to match the change in position is a good way to handle this. (velocity = frameOffset / dt;)
Using a more physical approach like the MotorizedGrabSpring avoids most special cases. However, don't get stuck on the idea that it's the MotorizedGrabSpring or nothing; there are many options out there (and the LineDisplayObjectBase is just another visualization tool, not a necessary physical object).
)