@Dan Grossman
I dont mean to be condescending to you… but I think you misunderstand what a design pattern is in the first place.
Comparing a “horizontal top navigation” to a design pattern (design patterns including things like MVC, OR/M, TS, CoR, Repository, IoC … etc) IMHO is incorrect. In front end web design, the horizontal top navigation “pattern” or as i would call it “trend” is more comparable to a functional piece of a site such as “membership” or “form processing”. Design patterns refer to best pratise methods in which to solve a problem. An easy example is the Repository pattern.
The repository pattern, which is well demonstrated by linq to sql (asp.net). It provides a data abstraction layer which allows your business logic to agnostically retrieve data whether it is from a database (whether mysql or oracle) whether its from an xml file or YML file, or whether it is checking a cache for the data first. The repository will also typically hide the calling components from things like sql and xpath. It typically will serve the calling components some sort of application structure representation of the data (IE linq to sql provides an object based view of data, think OR/M).
Keep in mind that linq to sql itself is not demonstration of the repository pattern, but the object query operators make it very easy to build one.
Ruby on rails uses active record for its data representation which I think is quite similar to a repository… in fact a repository could probably wrap an active record implementation.
I agree with PHPKick in sometimes needing to break out of the recommendations of a design pattern, such as putting small bits of business logic in the view. Esp in web programming business constraints are a large part of our work, having to get things out the door quick. But sometimes hacks like that really are the bane of software projects costing maintenance and making changes harder and more complicated to do.
Design patterns also help a lot with test driven development as they help you properly compartmentalize code into components that serve the next layer of calling components. So you can easily build tests to verify the functionality of nicely layered and component oriented code.
Your job as a programmer is to determine how important it is that all this be implemented. Obviously if you are making a simple script to collect some user data and save it to the database and send an email to someone you arent going to go about erecting a layered application with a repository and services that send email, and caching, and queues and what not, because your only getting 200$ to implement this script on a small site that probably wont receive more than 100 hits. So screw it build a quick transaction script that validates, db inserts, and emails the data and displays a thank you message. Easy and done. Profit made.
Now expand that into a larger site in which multiple features of a site do email sending and interact with a database. Well obviously there are alot of ways to go about this, you may have requirements to fetch data from some sort of REST service like iContact, or you might need to screen scrap some data from somewhere… so design patterns help you build such things so that email sending is built as component that can be used by other components (contact forms, or request a quote forms, or refer a friend type things).
Then with data access requirements you can build a single component that handles these data access requirements and that prevents you from having to duplicate and debug this code everytime you need to use it.
I guess in conclusion I think that design patterns are worth the time and money saved when you have requirements in which implementing a design pattern will save time and money. Yes, thats a bit of a weird sentence, and thats why you are the software engineer that needs to decide what is the best option in terms of completing requirements, adapting to changes, maintenance and business requirements, budget, etc.