Андрей

Для начала, для чего существует POST.
Представим, что у вас есть сайт example.com и на нем форма с кнопкой, удаляющаяя статью.
На сервере вы, естественно, проверяете авторизован ли пользователь и есть ли у него права на удаление.

При нажатии на кнопку через post передаются такие параметры
article_id: 123
action: delete

Если на сервере вы будете получать эти данные при помощи $_REQUEST, то возможна ситуация, когда злоумышленник делает так:

<img src="http://example.com?action=delete&article_id=1">
<img src="http://example.com?action=delete&article_id=2">
<img src="http://example.com?action=delete&article_id=3">
<img src="http://example.com?action=delete&article_id=4">

Публикует такие "картинки" вот прямо здесь, в комментариях на тостере.
При этом ваш браузер конечно попытается эти картинки получить, и выполнит эти запросы с ВАШИМИ правами.

В случае, если вы обращаетесь к $_POST - такой фокус не сработает. Кроме того, данные отправленные через POST не попадут в историю браузера и в логи той wi-fi точки или роутера, через которую вы сидите. URL попадет, а POST data - нет. В отличие от GET.

А $_REQUEST существует для удобства. К примеру у вас есть форма поиска, которая может работать и через POST и через GET. Это удобно, когда пользователь может скопировать URL с поисковым запросом.

но код, особенно после C++, не вызывает каких-то положительных эмоций.

А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

Да у языка есть просчеты, но их потихоньку сглаживают и устраняют проблемы.

3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

6) как хотите.

И так...

Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

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

Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

p.s. Haters gonna hate

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

Переписывать под свой велосипед - плохое решение.
Хорошим решением может быть: заняться настройкой yii, или профилировать свой код, чтобы найти узкие места.

Главный вопрос: проект хоть как-то в продакшене? у тебя есть хотя бы 100 пользователей онлайн, что ты переживаешь о 5мб? 1GB оперативки стоит 10 баксов в месяц на DigitalOcean, если что.

Свой велосипед почти 100% выйдет боком. Если прямо дико хочется оптимизировать, поищи какой-нибудь более производительный фреймворк, чем Yii и переползай на него. Мне когда-то нравился Phalcon.

Не важен путь, который выберете вы. Важно то, как вы его пройдете.
Самообразование - ключ к любой профессии. Никто и никогда вас не станет ничему учить. Забудьте об этом, все только сами.
Как, по-вашему люди из самых запдрыпанных мест становятся великими? Трудом.
Учитесь тому, что интересно. Хотите GameDev? Без проблем. Сейчас осень, впереди зима и весна. Садитесь за Java или Swift. Напишите к лету приложение и разместите его в магазине. Будет настоящий незаменимый опыт. Потом еще и еще. Не сразу, но начнете на этом зарабатывать. Было бы желание, остальное приложится.
И к экзаменам тоже можно подготовиться. И сдать их на отлично самому. Не смотрите на ленивцев вокруг. Они вас кормить не станут. Они так и дальше будут сосать пиво из бутылочки и сидеть на шее у родителей до последнего.
Или вы тоже хотите пойти на стройку, чтобы зарабатывать на пиво? Тогда вперед.

агрессивной критики в буржунуте намного меньше, чем в рунете.
посему учи английский, он и без этого нужен.

По большому счету, у вас два вопроса:
Можно ли хранить несколько классов в одном файле?

Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4].
This means each class is in a file by itself, and is in a namespace of at least one level: a top-level vendor name.

PSR-1
Проблемы такой подход может вызвать только если вы начнете работать в команде, в которой принят какой-то другой стандарт. При наличии современных IDE нет никакой разницы в каком файле лежит класс и поэтому нет никаких причин не писать каждый класс в отдельный файл - так их будет проще читать и искать.

Можно ли вызывать один класс через другой

$userLinks = User::getUserLinksObj()->findLinks($userId);

Если уж вы инкапсулируете, так инкапсулируйте так, чтобы было удобно пользоваться:
$userLinks = User::findLinks($userId);

Но в таком случае почему бы не написать сразу нормально?
$userLinks = UserLinks::findForUser($userId);
Зачем такая сильная связь между классами? У каждого класса - своя зона ответственности.

Никак.
Почему все думают, что в интернете можно зарабатывать без навыков? Вы же не можете устроиться на обычную работу без навыков. Интернет тут ничем не отличается: это обычная работа, только удаленная. Нет навыков = нет работы.