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. In the case of mixed .NET and Java, I'm not sure but I could only guess that in the MVC sense of things they've got Java acting for all the business model stuff and .NET handling everything else which would be better described as "middle-tier" but it's still all server-side.
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).
Client Side Languages
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.
Server Side Languages