It's a semantics issue. When somebody says a .NET front end or Java front end developer, they're usually talking about the person who knows a lot bout the templating languages and maybe frameworks that should never be used ever again like webforms that were used to try and hide the chucking of things over an http wall (i.e. "web development") from app developers who didn't want to or at least were assumed to not want to learn about all that crap.
The real separation is what happens on the server and what happens on the client or browser. You could easily conflate building the HTML to be sent to or representing the front end with "front end development" so I prefer avoiding confusion by using the terms client and server-side instead of front and back-end when discussing what I typically do, (usually client-side work).
The reason we use the same set of languages on the browser is because the browser is on the receiving end and for the most part (there's been now-mostly-dead resistance from Microsoft and Adobe on this) nobody wants to have to send out three different versions of the same client-side to satisfy every potential customer or require a proprietary plug-in be installed for the web to work. Also, the three languages actually encapsulate client-side concerns quite nicely, allowing us to rapidly build and modify web app front-ends by maintaining loose coupling between document structure, how everything looks and how it all behaves. You can change one without changing the other two quite easily.
The reason you have bazillions of options on the server-side of course is because you can. JavaScript is now an option btw but that brings up an interesting question. Should you still treat a web app like it's really two apps on either side of that HTTP wall. I'm of the informed-through-pain opinion that yes, yes you should and I love Node.js.