I strongly disagree. Automatic profiling only helps when you have a high-performance module and you want to prevent random commits from hurting that performance.
If you write a module with no regard for performance, because automatic profiling is still "in the green", you will spend your entire time budget (milliseconds-per-frame, milliseconds-per-request, milliseconds-per-megabyte, etc.) in the first half of your project and slowly realize that it's getting harder and harder to add new features without going into orange or even red territory. Sure, you can shave off 10% or 20% in "quick wins" with a bit of profiling, but nothing short of a rewrite can save you from inefficiency by a thousand cuts.
This doesn't matter if the module is not performance-critical, obviously. But when it is, then you should either plan for performance from the very start, or plan for a rewrite.
If you write a module with no regard for performance, because automatic profiling is still "in the green", you will spend your entire time budget (milliseconds-per-frame, milliseconds-per-request, milliseconds-per-megabyte, etc.) in the first half of your project and slowly realize that it's getting harder and harder to add new features without going into orange or even red territory. Sure, you can shave off 10% or 20% in "quick wins" with a bit of profiling, but nothing short of a rewrite can save you from inefficiency by a thousand cuts.
This doesn't matter if the module is not performance-critical, obviously. But when it is, then you should either plan for performance from the very start, or plan for a rewrite.