File extensions are not used because of the idea that URIs (and therefore URLs) should be independent of implementation – if you want to access the CDC’s information about food safety, you should be able to go to https://www.cdc.gov/foodsafety (for example). Whether the CDC’s servers are using PHP or Python or Perl doesn’t matter to the end-user, so they don’t need to see it. The end-user doesn’t care how the page was generated, because all languages serving a webpage output the same HTML, CSS, and the like, and the user is just viewing the page in their web browser.
Most web frameworks build this functionality in by default, precisely for this reason, and it can be accomplished regardless with URL rewriting in most webservers. This ideal is codified in the W3C Style Guide, which is undoubtedly a big factor in this idea being so widely accepted. It’s outlined in their guide, “Cool URIs Don’t Change”, which should clear things up if you still don’t quite understand the reasoning here. That document is the go-to statement on the issue, and the de facto standard for frameworks.
It is worth noting that usually files that end up being downloaded (and sometimes data files used in AJAX) will still have their file extensions intact – http://example.com/song.mp3 or http://example.com/whitepaper.pdf – because they are intended to be saved to the end-user’s computer, where file extensions matter. The extensions are not included for pages that are simply displayed – which is most pages.
A postscript: The example page this answer originally linked to stopped existing at some point, because sometimes URIs do change, despite best practices. I’ve replaced it with the CDC’s food safety page, which has existed in some form for at least 20 years now. Undoubtedly, numerous different technologies have served up that content over the years, while always doing so at the exact same URL.