I think "logs to code ratio" is a misunderstanding of the problem.
In my job I once in a while have a situation where a bug in a Java program cannot be reproduced outside the production environment and where the customer does NOT want it to happen again.
Then ALL you have available to you to fix the bug, is the information you yourself have put in the log files. No debugging sessions (that is forbidden in production environments anyway) - no poking at input data - nothing!
So the logs are your time machine back to when the bug happened, and since you cannot predict ahead of time what information you will need to fix a bug yet unknown - otherwise you could just fix the bug in the first place - you need to log lots of stuff...
Exactly WHAT stuff depends on the scenario, but basically enough to ensure that you are never in doubt what happens where :)
Naturally this means that a LOT of logging will happen. You will then create two logs - one with everything which is only kept around for long enough to ensure that you will not need it, and the other one with non-trivial information which can be kept for a lot longer.
Dismissing logging as excessive, is usually done by those who have not had to fix a bug with nothing else to go by :)
