Vasya Pupkin

Я думаю так:
1) JavaScript - высокая востребованность и зарплата
2) Java - высокая зарплата, средняя востребованность
3) C/C++ - высокая зарплата, не подходит для молодежи, низкая востребованность
4) перспективно Scala, Closure, Rust
5) в США наверное Objective C и Swift популярны

По технологиям:
1) Web Backend (centos, ubuntu, debian, Docker, Docker Swarm/Kubernetes, ansible, systemd, supervisor, nginx, haproxy, php5-fpm, nodejs, postgresql, mysql/mariadb/perconaserver, redis, cassandra, Consul, Ceph, ElasticSearch/Sphinx)
2) Web Frontend (html6, web 3.0, css5, es8, nodejs, gulp, grunt, browserify, angularjs, react, flux/redux, mocha, selenium-webdriver, protractor)
3) Android/iOS (менее перспективно BlackBerry, Sailfish OS, Ubuntu Touch)
4) Databases (ext4, Ceph, Oracle, PostgreSQL, Cassandra, ElasticSearch/Sphinx)
5) Big Data

Они мешают локализации бизнес-логики внутри вашего приложения. Т.е. бизнес-логика разделяется на две части и на два языка программирования. Рассмотрим каждый из недостатков по отдельности.

1. Бизнес логика разделяется на две части. Этот недостаток особенно проявляется при использовании веб-фреймворков и в частности паттерна ORM. В паттерне ORM при создании, обновлении, удалении объекта через шину событий вызываются обработчики события, в них и пишется бизнес логика, а хранимые процедуры этого лишают. Хранимые процедуры дают оптимизацию и у программистов есть недостаток к преждевременной оптимизации, что может привезти к резкому усложнению архитектуры и кода.

2. Бизнес-логика пишется на двух языках программирования. Во-первых нужно знать, хорошо знать, два языка. Во-вторых, нужно вводить Coding Style Standarts еще для одного языка. В-третьих, языки хранимых процедур (T-SQL, PLSQL и т.п.) не очень подходят для написания сложной бизнес-логики, а современные требования к бизнес-логике как раз требуют софистики. Вообщем код получается запутанным, нечитаемым, сложно модифицируемым и т.д.

Я признаю только триггеры, только util-триггеры. Например, триггер запрещающий удаление записей в определенной таблице, это можно сделать с помощью прав, но лучше дополнительно защитить триггером который будет распространятся глобально на всех пользователей. Второй пример, это триггер подсчета количества записей в таблице, как известно COUNT(*) на больших таблицах обходит весь индекс по PRIMARY KEY, а вообще большие таблицы зло - лучше сразу шардить.

P.S. На опыте скажу сталкивался с системой КИС УЗ Модус, разработчик отказался разрабатывать сервер и запил всю бизнес логику на T-SQL и вызывал их из клиентского десктопного приложения. Вообщем печальная была система.