В этом нет ничего ни хорошего/ ни плохого.
Если тебя интересует что происходит то:
Через GetComponent ты обращаешься на сторону движка чтобы получить компонент.
Это относительно дорогая операция и конечно если у тебя интенсивная симуляция с десятками тысяч объектов каждый кадр и все они обращаются по несколько раз к GetComponent лучше такого избегать. В простых случаях пофиг.
Пример прокрутки 10_000_000 раз с GetComponent и обращением к закешированному компоненту.
Редактор:
Profile GetComp took 1.723214700 seconds to complete over 1 iteration, averaging 1.723214700 seconds per call
Profile Cache took 0.047195000 seconds to complete over 1 iteration, averaging 0.047195000 seconds per call
IL2CPP сборка:
Profile GetComp took 3.347963100 seconds to complete over 1 iteration, averaging 3.347963100 seconds per call
Profile Cache took 0.028041700 seconds to complete over 1 iteration, averaging 0.028041700 seconds per call
Как видишь постоянное вытаскивание компонента примерно в 119.5 раз медленее на реальной сборке. Обращу внимание что это 10_000_000 вызовов за раз.
Код
if (Input.GetKeyDown(KeyCode.Space))
{
var c1 = default(LayerApp);
Profile.Start("GetComp");
for (int i = 0; i < 10_000_000; i++)
{
c1 = GetComponent<LayerApp>();
c1.v++;
}
Profile.End("GetComp");
var c2 = GetComponent<LayerApp>();
Profile.Start("Cache");
for (int i = 0; i < 10_000_000; i++)
{
c2.v++;
}
Profile.End("Cache");
Profile.PrintResults();
}
Как не мучаться такими вопросами.
1) Поузнавать что из себя представляет юнити. Блоги юнитеков и разные товарищи как этот помогут.
2) Замерять скорость на собранных билдах ( тебе понадобится профайлер и ты легко нагуглишь его )
3) Повторять пункт 2 до осознания бессмысленности этого. ( Со временем ты просто будешь примерно знать и помнить сколько какая операция стоит и обращаться к таким относительным замерам только чтобы сравнить какой алгоритм работает быстрее относительно другого.
4) Не страдать из-за вещей которые не только не понимаешь, но и не хочешь понимать. В 99% случаев проблемы инди с производительностью юнити игр - это проблемы с рендером, физикой, аудио, ассетами. Код игры редко является проблемой при условии что кодер обладает элементарной грамотностью и примерно понимает что он делает. Если этого нет - то лучше отложить юнити и поизучать отдельно язык программирования. При должном усердии и обилии информаций это не займет слишком много времени и сэкономит силы и нервы когда дело дойдет до написания игры в юнити 
Часто вижу компульсивные вопросы из разряда "а вот тут я хорошо написал? а вот это быстрее быстрого?"
