Columns like these should not be added because "the framework makes it easy" or because of some cargo-cult "best-practice" illusion. They should be added in case there is a real requirement, a real use case for them, something requested by a user or stakeholder.
For example, in a customer database, a company may keep track about their customers and business partners as well as their contact persons, by manually entering the data from several sources like mail, email, phone calls and information from the web. Unfortunately, such data tends to age over time and loose its currentness. So they may have a process to validate all customer data which hasn't been updated in a period of more than 3 years, for example. And I guess it is pretty be self-evident how columns like "created_at" or "updated_at" can be used to support such a process.
Or, lets say one implements a forum software or blogging system, or a system like Stackoverflow, where users can enter and edit their posts. In these systems, it is a usual requirement to keep track of when the posts where entered, or when they were changed last time, and show that information to the users of the system.
So in general, whenever a system manages data where it is important for the users to know the age or currentness of the data, introducing timestamp columns becomes necessary. And since in larger systems this can affect multiple tables and the implementation can often be made in a uniform way, it is not very surprising that certain frameworks provide support for this whole category of requirements.