Cookbook 1ed definitely had the mindset that you only use SQL databases for high-end high-complexity applications. But these days, if you have data then you probably have an RDBMS somewhere. It used to be that most people didn't know SQL, but these days it's almost a given. Now that SQL knowledge is ubiquitous, everyone wants their favourite data source to be SQL-queryable. And it ends up being easier to just throw data at an RDBMS than design your own DBM/MLDBM/flatfile/etc homegrown storage tricks.
So for a lot of the applications where MySQL is replacing a homebrewed pile of DBM and flat files, of course you don't need stored procedures and triggers and whatever other buzzword they're chasing today. That's the "MySQL rocks" point of view. The other side, "MySQL sucks", is where you have a large complex database with lots of activity--if you don't have stored procedures, triggers, and transactions, you'll find yourself losing data or having to reimplement their functionality in the client. And that almost always ends up being a lot of work with a painfully kludgy feel to it.
More philosophical thoughts on DBI and databases after I have some sleep