Not exactly, I believe. Putting the long line as it stands in a function improves readability and might improve reuse but doesn’t change the dependencies in the system. In my understanding, the fancily-named law of demeter suggests improving the maintainability of the whole program by making dependencies short-leashed.
The original example was:
namespace Example1
{
public class Player : MonoBehaviour
{
private void Start()
{
// This makes the intention more clear.
Vector3 position = FindCellCenter();
}
public Vector3 FindCellCenter()
{
// And here we just put all the bad stuff in one place.
// If we're lucky, this method can be reused and nothing
// of Something or Rectangle changes, but usually,
// we'll want to update these other components some day
// and this here breaks.
return gameObject
.GetComponentInChildren<Something>()
.GetComponent<Rectangle>()
.rect
.position;
}
}
public class Something : MonoBehaviour
{
}
public class Rectangle : MonoBehaviour
{
public Rect rect;
}
}
The law of demeter version would be something like this:
namespace Example2
{
public class Player : MonoBehaviour
{
private void Start()
{
// Clear intention.
Vector3 position = FindCellCenter();
}
private Vector3 FindCellCenter()
{
// Here we have a single dependency.
// Every Player needs its thing, but it can
// be anything as long as it has a cell center.
// Now, this can be reused in other classes
// like AIPlayer or TestBot, which work totally different.
return gameObject
.GetComponentInChildren<Something>()
.FindCellCenter();
}
}
public class Something : MonoBehaviour
{
// Everything is a something if only it has a cell center.
// Square and round things all have a center, for example.
public Vector3 FindCellCenter()
{
// Well, this is a square thing, so get the Rectangle.
return GetComponent<Rectangle>()
.GetCellCenter();
}
}
public class Rectangle : MonoBehaviour
{
private Rect rect;
// Rectangles should always have a center.
public Vector3 GetCellCenter()
{
// But not every rectangle needs to have a Unity rect as its data source.
return rect.position;
// Maybe our rectangle center is this:
//return new Vector3(0, 0, 0);
// because we only need it for a test class.
}
}
}
This is a lot more code and may not be needed in simple cases, but I still believe that as a general soft guideline, the rule guides developers into a direction that is more open to inserting new things or changing individual parts of a system.
And now comes the biggest disclaimer of any design pattern: If you’re not working in a team with multiple developers or the project is small, almost none of this matters, since architecture is all about managing large systems with developers stepping onto their feet. Basically, this makes sense if Dev A is in charge of creating Player, Enemy and Vehicle classes, where Dev B is working on the foundation of SomethingRound, SomethingSquare, and ThingThatDisappearsEveryThreeSecondsBecauseOurDesignersThoughtItWasCool.
I hope this doesn’t derail the original question too much, but I really enjoy discussing design patterns. 
Coming back to the performance question, I would apply the law of demeter to add variable caching during the optimization phase of the project like this:
public class Player : MonoBehaviour
{
private Something something;
private void Start()
{
Vector3 position = FindCellCenter();
}
private Vector3 FindCellCenter()
{
if (something == null)
something = gameObject.GetComponentInChildren<Something>();
return something.FindCellCenter();
}
}
If the original code already separated everything into wrapper functions, such a change can be made without causing any conflicts with other systems (developers!), so it makes sense to do it right from the start, but optimization may only be needed once the project is close to release, where large refactorings become riskier and time is usually short anyway.
