I'm nearly old enough to try to put my brain back to that time (I used Unix V7 on a PDP-11/45..) and I'm not sure the replies here are quite on the mark. Yes, if someone had suggested a 64-bit time_t back then, the obvious counterargument would have been that the storage space for all time-related data would double and that would be a bad thing. Also true that there was no native language support for 64-bit ints, but I don't think that is a show-stopper reason because plenty of kernel data isn't handled as compiler-native types.

I think the main reason nobody pushed back on a 32-bit time_t is that back then much less was done with date and time data. I don't think time rollover would have been perceived as a big problem, given that it would only happen every 100 years or so.

In the decades since we have become used to, for example, computers being connected to each other and so in need of a consistent picture of time; to constant use of calendaring and scheduling software; to the retention of important data in computers over time periods of many decades. None of these things was done or thought about much back then.