Programs that run in the background can make good use of handling a SIGSEGV, if only to log the fact that it happened along with the context prior to exiting. This gives not only an indication of what went wrong in a log file, but also useful information to include in a bug report. Yes, the signal can be ignored, but this is only through deliberate action and is almost always a bad idea (unless you are testing under an experimental kernel with a known buggy vmm subsystem).
Unfortunately, once that signal is caught, ANYTHING is suspect. For instance, using anything that allocates memory within the SEGV handler is very likely a bad idea. The same goes for variadic functions like printf(). So yes, while an app is handling the signal, it may not be doing so effectively, hence you only see traces of it in dmesg.
Anyway, yes, the signal is sent to the application, however SEGV is not a real time signal and can be merged by the kernel. I.e., if a program accesses memory it has no rights to access 15 times, there's a very good chance that only one SEGV will actually be delivered, depending on the timing of the illegal memory access.
In SEGV handlers, open() write() and close() are your friends and use a special debug log (i.e not a logging FILE stream that may have been opened previously).