Мимокрокодил

К сожалению, процессинг (да и URP в целом) - это не про производительность. Тут есть всего два пути - лёгкий, то есть просто отключить и придумать что-то другое и геморный - ковыряться руками и всё оптимизировать под конкретно вашу игру для телефона. Или, хотя бы, под мобильную платформу.
Это довольно трудозатратная задача, поэтому имеет смысл посмотреть в сторону готовых решений. Я не пробовал бесплатные варианты, так что хз что там норм, но вот то, что использовал я:
https://assetstore.unity.com/packages/vfx/shaders/...

Вам отлично подходит MoveTowards. Работает он следующим образом:
1) Сначала он берёт первый аргумент - текущее положение объекта.
2) Затем берёт второй - место, куда объект стремится в итоге попасть.
3) Прокладывает путь между этими точками, после чего отмеряет на этом пути расстояние, равной третьей аргументе - шагу.
4) И возвращает местоположение, куда вам нужно переместить объект.
Плюс этого метода в том, что вы никогда не пройдёте дальше цели. Выглядеть это будет как-то так:

using UnityEngine;

public class ClickMoveExample : MonoBehaviour {

	public Transform target;
	public float moveDelta = 0.1f;

	void Update() {
		if (Input.GetMouseButtonDown(0))
			transform.position = Vector3.MoveTowards(transform.position, target.position, moveDelta);
	}
}

Либо с помощью пустой ноды, либо разделив анимацию на слои (в аниматоре слева раздел Layers), либо использовать скрипт вместо анимации. Не видя иерархии и вообще самой анимации точнее не могу сказать, что-то из этого должно подойти

Если бы такое задание дали мне, я бы в фотошопе маску полупрозрачную сделал. Если оно анимировано должно быть, то и маску тоже можно анимировать. А вообще, указанный вами пакет с такой задачей должен справляться, типа можно разделить стену с окном на фрагменты и настроить для некоторых из них тени.
Если всё не то, то можно написать шейдер. Подсказки можете найти в этой статье https://habr.com/ru/post/425989/

Ответом на ваш вопрос будет функция, принимающая из меша модели массив вершин и для каждой пробивающая координаты на экране в WorldToScreenPoint() - отрицательные = за камерой. Но, как правило, объекты не усекаются на части, видимые и невидимые камерой, поэтому достаточно просто факта наличия на экране.
Поэтому, если вы не ставите перед собой задачу немного задолбаться, а просто узнать, рендерится объект или нет, то вот эта замечательная функция срабатывает только когда объект надо отрисовать на экране:
https://docs.unity3d.com/ScriptReference/MonoBehav...

Действительно лучший способ определить спецификации - эмпирический на большой выборке разных устройств. Коими, конечно же, одиночные разработчики не обладают. Но это не значит, что сделать тут ничего нельзя.

Вы можете начать со сравнительного анализа. Из предложенных мной способов он самый простой и быстрый. Достаточно отыскать несколько похожих на вашу игр и провести некое винзоризованное среднее значение критического минимума и оптимального максимума. Не обязательно искать именно те игры, что написаны на Unity, но будет больше похоже на правду, если авторами игр будут небольшие студии, или независимые разработчики.

Если вы захотите уточнить вашу гипотезу, можете продолжить ручной проверкой.

1. Место на диске
Просто посмотрите, сколько весит папка с собранной игрой.

2. Количество ОЗУ
Оценить максимум вы можете прямо в диспетчере задач, только проводите оценку не посреди главного меню, а в процессе максимума интенсивности игрового процесса. Также можете создать несколько виртуальных машин на вашем компьютере с разной конфигурацией и по очереди прогнать по ним игру.

3. Видеокарта
Оценить характеристики видео вы можете по загруженности игрой активными объектами и средствами, влияющими на отрисовку - шейдерам, освещению (трассировке лучей, отражениям и т.д.), постпроцессингу и т.д.. Тут зависимость простая - чем больше эффектов, тем круче видеокарта нужна, чтобы каждое обновление экрана всё это дело перерисовывать. Также почитайте про шейдерные модели. Например, та же 4 версия HLSL требует минимум DirectX 10 версии. Также грубо оценить видеокарту вы можете по тому же диспетчеру задач, сравнив значение столбца GPU во время интенсивной игры со значением мощности видеокарты.

4. Процессор
Оценка процессора самая сложная, т.к. в неё постоянно вмешиваются другие процессы. В том же диспетчере задач вы можете посмотреть, как сейчас ведёт себя процессор, плюс можете попробовать занизить его тактовую частоту или выделить игре больше/меньше ядер, чтобы посмотреть как она себя поведёт.

5. Прочее - интернет, звук и т.д.
Если ваша игра требует подключение к интернету, просто напишите "интернет". Если же она содержит механику потокового просмотра видео или стриминг, то также укажите скорость, которую можно замерить любой соответствующей утилитой. Если вы делаете игру для аудиофилов, укажите HiRes Audio. Если нужен контроллер - укажите какой. В остальном требования из разряда "это нужно или нет", а не "что конкретно нужно".

Ну и, напоследок, отзывы.
Люди так устроены, что никогда не начнут писать положительный отзыв, если не почувствуют в этом необходимость, а вот поругать игру выстраиваются целые виртуальные очереди. Вы всегда можете из негативных отзывов узнать, если с игрой что-то критически не так.

Как видите, данный процесс весьма трудоёмкий, а местами требующий специфических знаний. Потому порой проще воспользоваться услугами тестировщиков, или заглянуть на реддит. Например, в r/playmygame или в r/playtesters.

Вроде были дополнения для работы с мешами в юнити, но они $15++ стоят, и имеют функционал далёкий от того же бесплатного блендера, который предлагаю вам использовать. Также в блендере легче и приятнее анимировать модели, ведь можно управлять такими вещами, как веса костей, чтобы, например, при подъёме задней ноги не деформировалась геометрия крупа или хвоста.

Способов проверить наличие земли много, вопрос в конкретной игре. Самый простой - проверить столкновение коллайдеров.

Стандартные скрипты сверху имеют сигнатуру вида
public class [название] : MonoBehaviour.
MonoBehaviour - это специальный скрипт, дающий возможность нашему использовать некоторые стандартные методы, например:

void OnCollisionEnter2D(Collision2D c) {
	Debug.Log(c.gameObject.name); // выводит в консоль название объекта, с которым владелец скрипта столкнулся
}

Минус подхода в том, что ваш объект будет считать столкновениями в том числе и удары головой о потолок, что не очень сходится с задачей. В таком случае поступают иначе - создают в иерархии персонажа пустую точку, затем вокруг неё в коде ищут определённые поверхности. Выглядит обычно как-то так или так:

Код же будет выглядеть как-то так: