As it was stated by DeMarco and Lister in Peopleware some 20ish years ago, the vast majority of failed software projects fail not due to technical challenges, but sociological problems. This hasn't changed in the past decades, no matter how much our tools have improved.
Mismanagement, unrealistic expectations, failing to get the right people for the job, and/or not letting them do their job, consequently failing to keep them; workplaces and tools which are not suitable for SW development work; unhandled personal conflicts; politics; these are just a few of the typical problems which may make a project doomed from the start.
Why writing good code is harder?
I am not quite convinced it is really harder to write good code now than it was decades ago. In fact, compared to machine code or assembly, everything we have now in the mainstream is way easier to handle. Just we may need to produce more of it.
Is it only because of the mention factors, time and complexity?
Yes, the achievable complexity has certainly increased (and continues to increase) as the power of our tools increases. In other words, we keep pushing the boundaries. Which to me translates so that it is equally hard to solve today's greatest challenges as it was 30 years ago to solve that day's greatest challenges.
OTOH since the field has grown so enormously, there are way more "small" or "known" problems now than there was 30 years ago. These problems are technically (should) not (be) a challenge anymore, but... here enters the above maxim :-(
Also the number of programmers have since grown enormously. And at least my personal perception is that the average level of experience and knowledge has declined, simply because there are far more juniors arriving continuously to the field than there are seniors who could educate them.
Is it that methodologies are not practiced correctly?
IMHO certainly not. DeMarco and Lister have some harsh words about big-M Methodologies. They say that no Methodology can make a project succeed - only the people in the team can. OTOH the small-m methodologies they praise are quite close to what we now know as "agile", which is spreading widely (IMHO for a good reason). Not to mention such good practices as unit testing and refactoring, which just 10 years ago weren't widely known, and nowadays even many graduates know these.