I kind of get the historic rational. I had seen this issue reported on IXsystems pages as a potential bug.
I'm that sensitive as to find the absence of time-stamped messages distressing :) A bit more coffee should get through it ...
It just not useful when, for example, trying to work out when a problem occurs (e.g., under / not under load).
UNIX has a strong history of being built out of smaller, simpler, more robust components that can be combined to accomplish functionality. Some other systems were historically designed so that the "print" program would format your text file and send it to the I/O ports in such a way as to make the manufacturer's provided printer print your output. This presents a problem if you maybe wanted to use a different kind of printer, or save the formatted text, or do anything else that the designers hadn't considered. UNIX, instead, makes text formatting a separate issue ("pr file"), queueing ("lpd"), multiple printer types ("printcap"), printing to a remote site ("teh interwebz"), etc., so that you can pin all these bits together in whatever way you need, or even replace some of them ("CUPS").
The system message buffer is intertwined with console output for historical reasons, probably because UNIX mainframe operators were typically on duty and "paying attention", and would hear the console teletype printer or see it on their VT. But it was also understood that these things needed to be stored, so you can pipe the stuff to syslogd, and you can even set syslogd to send logging messages across the network for central recording, reporting, and analysis, where you pick up the timestamping and other meta-capabilities.
The downside to the syslog-maintained files is that they can be relocated, they can be intermingled with other messages, they can be huge, and they can also fill the disk, resulting in a loss of messages sent while the disk is full. I imagine that the authors of the periodic cron scripts felt that the use of the "dmesg" output in the daily report was a pragmatic solution to these problems. The system message buffer is always available (even if the disk fills), it is size-limited (the buffer has a defined size), and it is not mixed in with other messages, meaning that there's no need to process a potentially huge log file. But it isn't time-stamped. You should probably regard the message as a clue that something went awry on your system that you need to investigate further, rather than expecting it to be a comprehensive and complete problem description.
Mind you, my opinion is flavored by three decades of BSD.
Could you give a pointer for which log I should plow into? Thanks!
syslogd reads the system message buffer as it is able, timestamps the messages, and handles the messages as specified by /etc/syslog.conf.
For FreeNAS, it would normally end up in /var/log/messages, except security.*, which ends up in /var/log/security
