Please keep in mind I was speaking in generalities. I was purposely trying not to be overly specific. Some of my comments need not necessarily apply to the typical Arduino user. An example of this is one thread slamming in a new time while another thread is sleeping. Concurrency is not likely a typical Arduino user's concern. Though is possible if done via an ISR.
robtillaart:
(S)NTP is most used for synchronizing RTC's (or a software datetime lib) in Arduinoland. All RTC (but one) I know can be set up to 1 second precision, so in practice NTP and SNTP have "too much" precision for them. It would be nice if the millis() or micros() could be set according to the decimal part but unfortunately this is not possible on an Arduino AFAIK. OK one can create NTPmillis() and NTPmicros() that uses an offset or a hardware timer or ... So in Arduinoland the decimal part of (S)NTP is mostly dropped, and yes sometimes it is used for rounding to which second is nearest. IN fact 99% of the Arduino sketches would just need the Time protocol (RFC868).The Arduino has little resources and I assume that adjusting gradually for the drift for an Arduino is possible but it would take quite a bit of the resources leaving little room for the main sketch. (please let someone prove me wrong by building an Arduino NTP server library
The one second precision of the RTC mentioned before also means - from observing the apps discussed at the forum - that the RTC is seldom (never?) used for high precision timing, in Arduino context most people use millis() and micros() for this. The time of the RTC is mostly used for display and logging, and yes also for low precision timing like switching on/off the light of an aquarium or so. I see two different kind of clocks working side by side each for their specific purpose. And I think it is not bad.
I agree. Let's not lose track of the fact accuracy and precision is always relative to the purpose and requirements. For most people, accuracy to within a minute per year is acceptable for a wall clock. Whereas, accuracy to +- >2 minutes per week is pretty iffy. Still, for an electronics experiment its likely not a problem at all. For a clock beside the bed, its likely okay for the unemployed or soon to be, by the end of the year. 
Generally RTCs are a reference source of some type. This may include a square wave generator or simply periodic fetching of absolute time whereby interpolation is then used to synchronize CPU timers. As (IIRC) dbc said, there really isn't anything special about RTCs. He's right you can do it on common, non-specialized hardware if your tolerances allow and you use a clocking source which provides the required precision, and then take the time to calibrate and compensate with temp and so on. But then again, RTCs are so cheap, reliable, persistent with low power requirements, frequently with wake on interrupt (frequently allowing for additional power savings), typically fairly accurate, sometimes even highly precise, and all too often completely mitigate a whole slew of subtle software time management bugs, they become really hard to overlook - especially when no other external absolute time reference is readily available (time, sntp, ntp, etc). Whooo! That's a mouthful.
IMOHO, part of the confusion here people are conflating time with timers. Relative timers are easily possible without absolute time. Absolute timers require absolute time. Time, SNTP, NTP, and RTCs are all common sources for obtaining an absolute time reference. So the question becomes, assuming the easy path, do you require absolute time or relative timers; or both. IMOHO, if you require absolute time, your solution needs to include one or more of Time, SNTP, NTP, or an RTC. Again, you're requirements will guide, if not dictate.
Like with most engineering tasks, this is no different. Define your requirements. Understand the problem domain. Craft a solution. My primary purpose for chiming is is that many people don't define their requirements and frequently when they do, time is such a simple construct we all know, so its frequently falsely understood the domain is mastered. As such, crafting a faulty solution is all too easy.
As I've pointed out in another thread, time is subtly hard to get right. As long as you don't underestimate its complexities and truly define your requirements, you'll likely be okay. Otherwise, expect a bumpy road and lessons learned.