They have to use a different logger implementation for retail builds. It could just swallow/ignore log entries (and probably would ignore/disable a lot of logging channels), or pipe them to the game's console (maybe colouring channels), or a text file inside %appdata%, etc... You don't need to inherit an interface or anything to do this, a simple ifdef to select different implementations is often good enough.
So those game engines are incapable of enabling any logging in production code? They likely still need state in any case, unless they're opening and closing a socket or pipe with every log request.
It makes it convenient, but doesn't necessarily make sense. What is the one application that's running? Isn't this just a grouping of global variables into another (global) structure called 'application'? You could just make a few more globals instead and get rid of the grouping, or not even make them global ;) What if I want to launch a new process in the background, or send a message to another app -- in those cases there is more than one application in the problem domain..?
The best example I can think of is the one I mentioned, which is having a singleton to represent the application itself. Since there is only one application, using a singleton class to represent our application makes sense
I'm not familiar with iOS, but from scanning the UIApplication docs with, it seems to be written in the kind of OOP style where you dump a whole bunch of useful functions into a class and then inherit from it. This style also often uses singletons to make it easy to get at those functions. That's fine, each style to it's own, but this is still an arbitrary choice by the API designer to use a singleton as a restriction on the end-user developers usage. You could replace the UIApplication singleton by, inside main, making local variables for a window, an event queue, a URL fetcher, etc... and then having the choice weather to make them global variables (e.g. via a singleton) or not, ourselves (i.e. the end-user of the API).
An example would be the UIApplication class in iOS. UIApplication is implemented as a singleton because the class represents the application itself. I'm not saying this is the only way to represent an application, but it is a very intuitive and well established way of doing so.