There certainly was an element of punctuality that has been lost, but it goes both ways. Clients don't want to deal with this either: "Sorry it's 5:01pm. The dev will be back tomorrow morning. Enjoy being down for the next 16hrs."

I'm all-in for the kids these days sheesh comments, but if you think 'back in the day' workers had the constant availability expectation that we have in the modern era with cell phones, that's just factually incorrect. It wasn't only employees that reliably adhered to the schedule, it was also management. If that changes, both sides should accept the trade offs, otherwise you are expecting the employee to treat the schedule as sacred, while the employer treats the schedule as something which is changed on a whim.

Lazy unreliable people certainly exist, but they don't usually last that long in any role. Poisonous management practices that set people up for failure have a much longer shelf life and do more damage.

There’s a really big difference between providing coverage in an emergency and a butt being in a seat every morning. Every tech company I know of issues laptops that are taken home every night to production support employees for this exact reason.

Most developers are not in position where the client would have slightest idea when developer came in.

If you have regular hours long outages that require specific developer to come in and fix the code asap, you have huge mismanagement problem. The developers coming not in the morning is your least problem. Insufficient testing, apparently badly set up servers+application and most likely general mismanagement are primary problem.

Also, if you are in this situation, then it is reasonable to assume that your developers had to deal with similar outages in the middle of the night or during weekends.

If that's the situation, either the boss needs to call, or one of the other equally capable people in the office should be able to fix it.