That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece of hardware, we just requested it and it materialized. Often I didn't even know the per-customer unit price of the software. The only constraint that ever made it down through the huge tree of managers was the due date. Someone five managers above me was probably sweating the budget but to us low level developers, budget was never even a concept.

To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always inherent, or that this functionality actually is not really needed because the problem can be fixed in an operational way, or that the requirements have changed, or that it was just a nice-to-have... but money/time don't have this grey areas.

The corollary is that it's only the budget that is tracked that anyone cares about.

Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.