I don't know what you mean by less performance impact; ltrace works by putting software breakpoints into the functions you want to trace, and such breakpoints work by causing a soft interrupt (e.g. INT 3 on x86), which causes a drop into kernel mode and invokes the appropriate interrupt handler, then the kernel suspends the process that caused the interrupt and queues the ltrace process which is ptrace-ing your app to be woken up when the scheduler thinks it's convenient, then ltrace has to write out its output after it figures out why it was woken up, yadda yadda, etc etc... overall it's pretty heavy-weight in comparison to a log message, but in practice is probably only a negligible performance impact for 99.9%+ of programs.
One shouldn't remove asserts() just because you're going to ship code, you just #define assert() to expand nothing. Same applies to languages other than C that don't have a pre-processor: you can define a null function, and hopefully your runtime is awesome enough to optimize calls to it away.
Using strace to trace mysql traffic is painful. You have to know which file descriptors to trace (check via lsof first), then trace all network traffic on those fds in verbose mode to see the queries themselves (doesn't work if the mysql protocol has compression enabled), and then try to figure out how long each of the queries took to execute by matching queries and responses.
ltraceing mysql_send_query() gives you all this information in one line.
Plus, you can trace a lot more than mysql queries.. commonly used libraries like libMagick, libxml, libcurl, libmemcached, and even internal VM functions like garbage_collect(), PyEval_SafeThread(), etc.