Some stuff just doesn't need optimizing. Basic IO, for example, is almost always going to be limited by the speed of the device being communicated with. Event handling is another example. No amount of assembler will basically speed up having to wait for an asynchronous event to happen.
This is a good argument when thinking about a single process or thread, but on multi-tasking systems like the Amiga a different process may be able to use the open processor time for further computation. Thus an optimized I/O routine would be preferable to an unoptimized one in terms of overall system performance.
If I had unlimited time I'd probably want to write everything in assembly to be the most efficient possible. But, since I do not, the question boils down to priorities. If it will take another 100 hours of coding to rewrite the I/O system to save only a few cycles, it's probably not worth it unless overall system speed and efficiency are the priority. In most cases the 100 hours would be better spent speeding up the most used code sections.
In addition, there is the case of specialization. Very few people can say they are experts in all areas of computer architecture. There are many cases where I'm fairly certain I would not be able to improve upon the work of others. For me, I/O is one such case. I'm content to trust that the authors of the I/O library have done their homework and made their code as efficient as possible.
And the original poster made the claim that with assembler...
you get the absolute best speed and efficiency from your code...
Clearly this statement cannot always be true. In the right hands an assembly program can be a masterpiece, but in naive hands it can be a disaster. Writing efficient assembly code takes skill and extensive knowledge of system architecture. If one doesn't have this knowledge, C would probably be a better choice--unless, of course, the goal is to gain this knowledge.
