Because it is wrong. Time is a difficult problem to solve, it doesn't move at a constant rate, the length of days and years change. You simply cannot set a constant and have it be "correct".
It may be more performant to set time ranges as constants, but you will get in to trouble unless you know exactly what you are doing. The people at Twitter who wrote the code will be aware of the trade-offs they have made, but what happens when Jo Random developer forks it on GitHub without thinking it through because "it's fast and Twitter use it - it must be good!"
For example:
T_1_MONTH = 2592000
Not all months have 30 days.
T_1_SOLAR_YEAR = 31558150
A solar year, is (roughly) 31556925.25218 seconds[1].
Just by the mere fact that these are constants documented to be in seconds, it's clear that they shouldn't be used for sensitive or precise time calculations. If you're at the point where you don't realize this, you probably aren't going to be able to use a full-featured time library correctly, either.
"Difficult for novices to use incorrectly" is a good feature for code to have, but it's not the highest good, and its absence does not mean that the code is bad.
It may be more performant to set time ranges as constants, but you will get in to trouble unless you know exactly what you are doing. The people at Twitter who wrote the code will be aware of the trade-offs they have made, but what happens when Jo Random developer forks it on GitHub without thinking it through because "it's fast and Twitter use it - it must be good!"
For example:
Not all months have 30 days. A solar year, is (roughly) 31556925.25218 seconds[1].[1]http://www.wolframalpha.com/input/?i=seconds+in+a+solar+year