If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you

If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you don't have to worry about adding/dropping an hour to the length of things when some sort of DST event happens, just using local time across the board is simply easier. Of course as soon as one of those assumptions is not 100% true, using UTC internally and local time for display is usually by far the better option (though there can still be difficulties there – time is never as easy as you'd think it should be). The trouble comes when people use to working local only (timezone wise) slap together a PoC of something that might need timezone awareness, and don't fix the deficiency at any point as they progress through PoC->prototype->alpha->beta->v1. The longer you leave the change the harder it is to do, and it not being easy is why once something nominally reaches V1 (or often at first alpha release) such a fix is seldom ever made. Timezone awareness has improved massively in recent years though. I think some cloud providers have accidentally helped there by defaulting to UTC (for instance all AzureSQL DBs default to UTC for everything, as do VMs and other things in Azure). Though here in the UK minor issues due to bad assumptions are still common when we transition back or forth between GMT and BST.