Consider caching Transform changes

The Transform Component stores data only relative to its own parent. This means that accessing and modifying a Transform Component's position, rotation, and/or scale properties can potentially result in a lot of unanticipated matrix multiplication calculations to generate the correct Transform representation for the object through its parent Transforms. The deeper the object is in the Hierarchy window, the more calculations are needed to determine the final result. 

However, this also means that using localPosition, localRotation, and localScale have a relatively trivial cost associated with them, since these are the values stored directly in the given Transform and can be retrieved without any additional matrix multiplication. Therefore, these local property values should be used whenever possible.

Unfortunately, changing our mathematical calculations from world-space to local-space can over-complicate what were originally simple (and solved) problems, so making such changes risks breaking our implementation and introducing a lot of unexpected bugs. Sometimes, it's worth absorbing a minor performance hit in order to solve a complex 3D mathematical problem more easily.

Another problem with constantly changing a Transform Component's properties is that is also sends internal notifications to Components like Collider, Rigidbody, Light, and Camera which must also be processed since the Physics and Rendering Systems both need to know the new value of the Transform and update accordingly.

The speed of these internal notifications were improved dramatically in Unity 5.4 due to the reorganization of Transforms in memory in Unity 5.4, as mentioned previously, but we still need to be aware of their costs.

It is not uncommon, during a complex event chain, that we replace a Transform Component's properties multiple times in the same frame (although this is probably a warning sign of over-engineered design). This would cause the internal messages to fire each and every time this happens, even if they occur during the same frame, or even the same function call. Ergo, we should consider minimizing the number of times we modify Transform properties by caching them in a member variable and committing them only at the end of the frame, as follows:

private bool _positionChanged;
private Vector3 _newPosition;

public void SetPosition(Vector3 position) {
  _newPosition = position;
  _positionChanged = true;
}

void FixedUpdate() {
  if (_positionChanged) {
    transform.position = _newPosition;
    _positionChanged = false;
  }
}

This code will only commit changes to position in the next FixedUpdate() method.

Note that changing the Transform in this manner does not result in strange-looking behavior or teleporting objects during gameplay. The whole purpose of those internal events are to make sure the Physics and Rendering Systems are always synchronized with the current Transform state. Hence, Unity doesn't skip a beat and fires the internal events every time changes come through the Transform Component just to be sure nothing gets missed.