@Vic
Your first point made sense, then you kind of threw it all away.
The vast majority of software employment is maintenance - an application already exists, it must be extended to add new features and bugfixed to correct the mistakes and incorrect assumptions made in the past.
Do you think you can choose to write your new features and bugfixes for a C# program in Java, or a LAMP stack in HLSL?
There are only two situations where it's possible to choose the language and framework for a task:
A) It's a brand new project, and will not be using any modules that company created for previous projects.
B) The project is to port an existing product to a new language or framework - in which case the programmer rarely gets to choose because they're being employed/directed to do that particular port.
In all other cases, the language and framework are pre-defined by history - either by the modules you already have or the program it is extending.
Even in case A), any software company will have a set of preferred languages and frameworks, and as a programmer you will write in the one chosen for that project.
In a good team you'll be able to influence which language and framework are chosen, but at the end of the day it will be selected and whether you agree or not, you will write that project in that language and framework.
Your post implies that you've usually been writing-from-scratch on your own, and that's not they way most people earn their corn.
University education is often the first time people are held to a specification - coding at home you can make the program do whatever however you like, but in the real world there are specifications to meet and other people and teams to work with if you want to get paid.
It's pretty rare for the requirements not to define the OS(s), language or framework.