This got me to wondering, which does HN use and why? Are there any discernible trade-offs of using either one?
Another reason to use a TIMESTAMP or DATETIME type is you can use date/time operators and functions on it easier. For example timestamp_column + INTERVAL 30 DAY (in MySQL) is clearer than having to convert an INT.
Every relational database has more than one date/time type in case you only need dates without times, for example.
For @gregjor's answer (having the DB create the date for you), it seems that if you actually need to know the timestamp of a newly inserted or updated record, you will actually need to make 2 SQL calls, since the record itself is not returned by UPDATE or INSERT.
If you are getting the date/time value outside of the database -- from a web application, for example -- and using that to insert into the database you will run into inconsistencies eventually because clocks on different will not be synchronized or will be set to different timezones. In my experience it's more important that all date/time values in a database come from a single source (the database server itself) rather than which column type you use. It's easier to control the clock and timezone in one place than require all database clients to be set to UTC and have their clocks synchronized.
Setting all clocks to UTC is not enough to get around daylight savings time issues, either. You actually have to know the timezone to do accurate date arithmetic. You can find lots of articles about this -- it's a pretty well worked-through topic. Think for a minute why every operating system and RDBMs and programming language date/time library aren't just using integers and assuming UTC.
Date/time types are native types in all serious relational database engines, so there's no conversion going on that you need to worry about. All RDBMSs have mature date/time manipulation operators and functions. If you use large integers you are going to be doing more conversions, especially once you have to deal with timezones. Think it through.