In my OSS existence I do a lot of library work aimed at performance, that is deeply tied to the caller's data-structure (i.e. external to the library), with (by design) no mandate over the incoming types. Here, the best way to make this performant is meta-programming, which (since I'm in .NET-land) means IL-emit. That is some ugly, ugly code, but very fast.
In this way, I happily accept library code may be "uglier" than application code, simply becuase it has less (or maybe no) control over the inputs, so needs to achieve some tasks through different mechanisms. Or as I expressed it the other day:
"coding over the cliff of insanity, so you don't have to "
Now application code is slightly different, as that is where "regular" (sane) developers are typically investing much of their collaborative/professional time; the goals and expectations of each are (IMO) slightly different.
IMO, the answers above that suggest it can be fast and easy to maintain are referring to application code where the developer has more control over the data-structures, and isn't using tools like meta-programming. That said, there are different ways of doing meta-programming, with different levels of insanity and different levels of overhead. Even in that arena you need to choose the appropriate level of abstraction. But when you actively, positively, genuinely want it to handle unexpected data in the absolute fastest way; it may well get ugly. Deal with it ;p