Dark Hole

Но можно ли при этом узнать что человек пишет, с кем общается?

Он может перехватывать весь ваш трафик и читать его. Но если трафик https. то он зашифрован и ничего прочитать не получится. Можно конечно попытаться устроить перехват https но только при условии, что вы не следите за сертификатами.

Но может ли он как-то палиться внутри сети?

Смотря что вы подразумеваете под словом "палится" - если речь о перехвате трафика, то нет. Если речь о определении факта использования TOR - запросто.

куки, может они как-то связаны с логином?

А то!

Смотрите что отправляет браузер в момент логина включая все заголовки, все куки, все тело POST и все параметры в нем (не что он должен отправлять исходя из структуры формы, а что в этот момент на самом деле отправляют скрипты) и сравнивайте с тем, что отправляет ваш парсер.
Бывает, проще прочесть скрипты, понять их логику и переписать на питон. Бывает наоборот, обфусцированный скрипт на несколько тысяч строк, тогда проще анализировать сетевую активность в момент совершения действия (логина, например), пробовать разные варианты ввода, наблюдать как зависит передаваемое от введенного, выявлять закономерности и имитировать подобный алгоритм на питоне.

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

/dev/null

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

$('.sub-menu_lvl1 li a').mouseenter(function() {
    var classes = ['one','two','three','four','five']
     
    $('.sub-menu_lvl2').removeClass('info-visible');
    $('.sub-menu_lvl2.' + classes[ $(this).closest('li').index()]).addClass('info-visible');
  });

Но это не самый лучший вариант. Лучше для линка на который вы наводите прописать id или data атрибут такой же как класс который нужно сделать видимым (one, two, three, four, five ) . Ну и при наведении выбирать это значение.
тоисть ссилка должна быть <a href="#" data-visibleclass="one">...</a> и тогда:

$('.sub-menu_lvl1 li a').mouseenter(function() { 
    $('.sub-menu_lvl2').removeClass('info-visible');
    $('.sub-menu_lvl2.' + $(this).data('visibleclass')).addClass('info-visible');
  });

Шаблонизаторы типа Smarty, Twig в 2017 востребованы, если с ними раньше не работал стоит ли смотреть, изучать что бы повысить ценность свою на рынке труда?

Smarty - вряд ли.
Twig - вполне себе актуален, я Вам даже больше скажу, он уже интегрирован "из коробки" в довольно популярную CMS по имени Drupal 8 (т.к. он сделан на базе Symfony) и собственно, в не менее популярный фреймворк под названием Symfony. И, Twig отлично встраивается в очень популярный фреймворк (я имею в виду, в ракурсе PHP-*) под названием Laravel, который в свою очередь так же имеет свой весьма неплохой шаблонизатор, под названием Blade.

Среди прочего, вариация Twig'а есть даже для JS (Node.JS), в качестве альтернативы таким штукам как Pug/Jade например. *По информации одного из наших коллег, такие шаблоны (в JS-вариации интерпретатора) отлично переносятся потом в оригинальный Twig/PHP (имеют хорошую совместимость/переносимость).
*Сам не проверял, но, доверяю словам автора.

Или их нативный php всё же их вытеснил

Из тех шаблонизаторов, что я могу вспомнить, по моему, все "компилируются" (преобразуются) в нативный для системы код (даже Smarty), т.е. если мы говорим про PHP - то соотв. в PHP-код. Парсится шаблон в код не часто и разница в производительности довольно не значительная, в 99% случаев - ей можно принебречь.

или все ушли во Фронтенд шаблонизаторы?

У них обычно немного разные категории задач. Если Вы говорите про шаблонизаторы аля Pug/Jade - то, что из них выходит, в конечный не-JS код, интегрируется плохо. То есть, смысл от этого шаблонизатора только для того, кто делает вёрстку, практической пользы при переносе на PHP-движок (и другие не JS-движки) от него обычно нет, либо очень мало.

Если говорить о чисто клиентских реализациях - генерировать данные на клиенте, в таком объёме, по моему, не кошерно в подавляющем большинстве случаев, с учётом того, что сервер может кэшировать страницу целиком и выдавать сразу готовую (Varnish, например, это если говорить о необходимости высокой производительности), а какой-нибудь полу-мёртвый смартфон, бедолаги, который зайдет на подобный сайт - лопнет от чрезмерного изобилия JS-кода.