Hmm... the problem is not in using the API, the problem is using the wrong API for completly incorrect purpose - simply because you don't have an appropriate one. And forcing the usage of the same one just because it's there.
If you are loading a 1000 users into the database, from a web application... would you use a method which everytime for each user goes to the database, and adds them one by one? Yes you would (at least you do in source, many times over)... because you have create user API. Instead of thinking... ok this is a bigger batch.... maybe I need to develop a batch insert functionality which inserts for example 100 by 100 users, which can be performant and scalable in the long run?
One good example of this are Portal Templates.... lately I've been digging into the source because of some performance problems... and one example which I was horrified to find is when you are exporting a list of tabs to a template... for each tab the export procedure goes to the database to fetch it's modules, using the API. Now, if you have a small site... ~50 tabs you won't see the problem... but if you have a bigger site ~1000 pages... you will probably feel the pain... let alone other parts of the template. And that's because your using the API. And you could have written a query which in one pass gets all that info and only goes once to the database... but of course you would not use the API. And usually portal templates and such tools prove their worthness with bigger transfers and bigger loads, when it doesn't pay of to do it manually but instead have a tool which can automate the daunting task.
To conclude... I don't have anything against using dnn API, but to push it to users and to say and use it for every purpose, just to prevent the changes from occuring is just plain wrong in my opinion.