The historical answer is of course that it originally didn't store the creation time, and nobody felt compelled to add this new feature.
There's a good reason for not storing the creation time, which is that this is a very poorly defined notion. If the system kept track of some time and called it “creation time”, there would be a lot of cases where this would not be a useful time.
Many applications save a file by first writing to a temporary file, and then renaming the file to overwrite the old one. This approach is preferable to overwriting the file in place because if the application or the system crashes while writing the file, this only leaves a temporary file around, whereas the overwrite method leaves a broken file in place. But this approach means that if you define a file's creation time as the date the file was actually created, then most data files would have a creation time that's the same as their modification time, or only a fraction of a second in the past. So the creation time would not provide any information.
This could be changed by requiring the application to somehow declare that the new file is in fact a new version of the old file, and so should inherit its creation time. But that would require a lot of extra complexity, unlike the traditional timestamps (content modification, access, and inode change) which can be updated automatically (on each write, on each read, on each metadata change).
There are other cases where the creation time is debatable. When you copy a file with preserved metadata (
rsync -a, …), are you creating the copy, or are you copying a file including its creation time? When you restore a file from backup, should the creation time be restored or should it be the time of the restore?
If you want to make the creation time of a file meaningful, enter it under version control. Then you can define the creation time as the time of the first commit that includes the file, and this information will be recorded and preserved.