A cronjob to sync the time instead of a proper NTP client doesn't sound that good either. I know that each place has its own weird things because historical reasons but NTP is quite ancient.
Our sysadmin was being paranoid about how many memory-resident programs we ran. he figured time syncing wasn't important enough to justify a daemon, so he just ran the ntpdate command on a daily schedule. It wasn't that bad - after all, how far can clocks drift in a single day!? ;-)
For security? Kerberos usually has a 5 minute tolerance. Are you saying that's wrong? Because if your hardware/firmware isn't literally broken you won't drift anywhere near that in a day.
NTP can't properly fix a clock like that either since it's often capped at adjusting the speed by one part per two thousand. At most, with a consistently wrong clock, that can handle about 30 seconds per day. Any worse than that and you won't see much advantage over ntpdate.
The bigger the clock skew, the harder it is to correlate events from logs. The harder it is to corelate, the more information needs to come from your machine-fueled winnowing stage, to the final inspection by eyeballs.
1-2 seconds is (probably) well within manageable. But, since you now know for SUER that you have clocks running at different speeds, you need to over-estimate the skew. And hope that the daily skewing is approximately constant over time.
So, yes, clock skew can have an impact on your security, because it makes event correlation (and followup on security incidents) harder.
"It makes logs more annoying, and sometimes security needs logs" is a pretty weak connection, though. And it's a far cry from precise timing being "THE most important thing on a server". Is there anything more direct at all?
after all, how far can clocks drift in a single day!?
Well, having run a Linux kernel on OpenBSD's vmm: they can drift more than a single day in that time. I did have to resort to using an ntpdate cron job because ntpd just couldn't cope with the time dilation effect. The cron job was configured at * * * * * (i.e. every minute), which roughly translated to once every 180 wall-clock seconds (+/- 30s).
Delivering real functionality in production (with code review from your mentor, of course) is absolutely standard at a Big Tech or hot startup internship.