It is probably because your 'average web monkey' is not building anything where there would be a massive impact if it did not degrade gracefully or was not fault tolerant at the application layer. The number of people and systems using what they build and the business impact of downtime is not high enough to require they manage degradation in software. If a component that a mechanical engineer was designing failed it could mean human death or injury or large costs.
For most people, any monitoring where it is done at all, will be performed on the infrastructure (CPU, memory, disk i/o, network utilisation). Any fault tolerance will also be performed by the infrastructure e.g. redundant servers, database backups; usually provided by their hosting vendor. The development framework will also provide some fault tolerance e.g. try / catch blocks, databases that can perform two stage commits.
However any serious developer, any enterprise developer that needs to build and support a business critical application is going to be thinking about graceful degradation and fault tolerance. Any major project I have worked on we have had this as a non functional requirement. The whole solution will also have challenging requirements for availability and performance e.g. 99.999% uptime 24x7x365, zero RPO, 2 hour RTO, 4 second end to end response time for all services. The developers and architects have a role to play in delivering these requirements and will often be on the hook as what they build will get tested against these requirements in performance testing including fuzzing of software components.
The system architecture these days will generally use loosely coupled components where the failure of component will have should not mean the entire system crashes. Practically the infrastructure will still play a large role though e.g. active-active sites, distributed DNS, content delivery networks, use network Quality of Service (QOS) to prioritize certain types of requests or from defined source IP's, use the capability in a web application firewall to prioritize requests to certain pages on the site, use provision on demand capabilities in your virtual machine to thaw out some pre-configured VM's and automatically load balance across to them.
There has also been some really interesting innovation where the status quo stack had fault tolerance but was not fit for purpose. E.g. Twitter and Facebook found performance and scaling limitations of SQL databases and the synchronous nature of most web applications. From these you get No SQL databases and technologies like node.js that provides the performance and scaling with fault tolerance in a different way.