I thought it would be beneficial to specifically mention query strings, since they are an integral part of dynamic website design and you hadn't mentioned them previously.
Expanding on a point is appreciated.
I don't claim to be an expert on content negotiation, but from my own point of view, a site utilizing mod_rewrite and a single script to output pages is a more secure, robust, and future proof way of web design, though it takes more planning and a more thorough knowledge of both the scripting language and regex, both of which can be difficult. Whereas content negotiation seems to be directed at an audience that is content with a more static solution that is easier to master.
The purpose of content negotiation is to let the browser and server pick from among multiple content representations, differentiated by file extensions. mod_rewrite lets you use a non-identity mapping from URIs to content. Neither is targeted towards a specific internal site layout, though content negotiation does target filesystem based storage. If you're implementing a CMS, which stores many resources in a DB, you'll need the non-identity mapping of URIs to resources of mod_rewrite, but you can also use the extension agnosticism of content negotiation to hide the file types of the script(s), images &c. A complex and well designed site may use both rewriting and content negotiation for different purposes.
As for a single script being an overall better site design, it's highly dependent on the site needs and internal design. If you don't know what you're doing, it's easy to use a single monolithic script that treats everything a special case; each of these two flaws make for a decidedly non-robust and non-future proof (in that it's not very maintainable) design. The single script should mean a single entry point; multiple scripts, broken down into modules, would actually be used (which, I assume, is what you're talking about). At the highest level, the entry point functions as a dispatcher, nothing more (though other patterns might be appropriate for specific problem domains). Dispatching is a also task for web servers. In some cases, it's better to have a script handle the dispatch; in others, it's better to leave it to the server.
For a CMS, you could also have a main entry point on the frontend that's a template processor with a few other entry points for form handlers. Depending on the template capabilities, the other entry points may not be needed.
This analysis is incomplete because I'm straying into territory that's hard to analyze without specific test cases. I'm also still formulating a conceptual framework that could cover the multitude of solution domains. In addition, I haven't yet taken performance into account. This is all far beyond this thread's topic. Do you want to discuss this in a new thread? I bet we could come up with a useful theoretical design framework that would apply to extant web technologies and perhaps determine which are suitable to use when solving a given problem.
I don't think yours is a bad solution by any means. I disagree that it is the only solution "that cuts the mustard."
The mustard I mentioned is type-via-file-extension agnosticism. For example, suppose you want to refer to /images/foo.jpg and /images/bar.png, but without the file extension. You can do it with mod_rewrite by adding a rewrite rule for each image, but that scales terribly. You could also rewrite the URL to a script that scans the image directory for the image and either returns the content of the image file or redirects to the image, but that's just duplicating the functionality of content negotiation. Third option (which you see in the wild) is to rewrite the URL to point to a script that fetches the image from a DB; viable, but slower than using the filesystem. DB storage of images is also more complex with no real benefit, generally speaking.
Once you require other functionality, such as fine grain access control, other tools will come in to play to allow you to spread the ketchup, sauerkraut and other condiments.
