Corporate Culture
While you have framed this as your employees challenging you, I would suggest you view it as a scenario where you have challenged your employees, and the result is not looking good for you. I'm not sure if you have noticed, but software engineering has some of the highest worker demand of any field. It also has very short tenures, for the simple reason that it is easy for workers to move up (or even just sideways, to gain more experience in a different area). What that means is that engineers generally have more leverage than employers (and why so many employers are willing to engage in illegal non-compete agreements). If your company were holding its SDEs in "golden handcuffs" (total compensation so high, they could not reasonably find it at another company), then I would expect near-total compliance. Open defiance like you describe may be seen as unprofessional, but it's also an indication that you have not accurately weighed the marketplace and the market value of their skills vs. their comp. If their comp is below market, then I would expect them to be especially contemptuous of petty demands.
The idea that corporations are strictly hierarchical organizations with directives that always flow downwards smacks very much of "central planning," which I hope we agree is a failed paradigm that should have died out in 50's and 60's. It's the idea that the CEO and the rest of the C-suite are the smartest people in the company, and everyone else is rank-ordered in intelligence and decision-making capability by their level. That kind of thinking might have been in vogue 50 years ago, but it simply isn't going to get you very far in a modern corporation with software engineers, let alone a tech company (you didn't say what kind yours is).
Empowerment
If your engineers were building widgets in a factory, then showing up on time so the assembly line can start and operate at capacity would be a justifiable organizational demand. However, knowledge work has no strict assembly line which dictates working hours, and the mental intensity of software engineering will especially reward a certain amount of managerial flexibility in scheduling.
Many engineers prefer to arrive really early or work really late so that they can enjoy a mostly-empty office, which improves their productivity. Requiring that everyone arrive at the same time is the same as demanding that everyone expose themselves to a constant barrage of emails, meeting requests, and impromptu desk interruptions. That isn't good management. That's a power trip.
Team Meetings
The only time you can really expect engineers to show up on time is for team meetings (like a daily standup, for instance). That in itself is the justification for a time expectation. On the other hand, if the team thinks you are setting a meeting time for your own convenience, and at the expense of their priorities, then you will win their hard-earned resentment, rather than respect. It would be best to set such meeting times in collaboration with the team, rather than dictating a time. Obviously, if your engineers need to interface with folks from other teams or clients at a particular time, then there should be no dispute on the importance of being present. You didn't mention any such requirements, so I am assuming they don't exist.
Management Expectations
My last employer went through many iterations of the org chart, constantly changing the scope and expectations of the management org. I would say if there is any general trend in tech management, it would be a steady erosion of responsibility. While managers in most other fields are expected to provide work assignments and priorities, interface with other teams, perform HR duties and recruiting, I would say that in tech, the focus is moving away from the front of the list and towards the back. If this trend has not reached your company yet, perhaps you are fortunate. It doesn't mean that your workers are in sync with you, as you have noted. Quite often, a conversation will include: "Well, at Facebook, they do X" or "At Google they do Y" or "Amazon doesn't do Z, why do we?" Know that your engineers almost certainly have friends and ex-coworkers at other companies, telling them what corporate culture is like where the grass is greener. If you insist on making the grass brown for your team, then you'll find a lot more of your time spent on recruiting. Time to decide what is most important to you.
Going Forward
My first piece of advice is to think very hard about why you expect your software engineers to do something that almost no other competitive employer will demand. Is there an actual business need driving this requirement? If so, then share it with the team and start a discussion; but be willing to listen and to compromise. If the only reason is your personal sense of discipline and corporate decorum, then I must respectfully submit that your values are out of sync with the rest of the industry, and you will need to work extra hard to build a team that aligns with you on this while also providing sufficient value on your deliverables.
Second, I would suggest you ask yourself what value you deliver to the team. How would the team fare if you simply didn't show up to work tomorrow? Would everything fall apart? Would they just goof off? Or would things continue to run smoothly until they needed to make an important decision that requires your input? If you are personally holding the team together by the sheer force of your will, then I'd say you have an unhealthy, dysfunctional team. If the team could do just fine without you for a week, then they certainly don't need you to man the door with a stopwatch, counting down the seconds until they arrive in order to deliver the value that your team provides.
Hopefully, the value which you bring to the team is strategic, not trivial. Ideally, your team looks to you to make difficult judgment calls, help them weigh risks, provide insight from higher levels of management and connections you have across the company. If so, you're doing well. But that also means you should measure the things that are important, and leave alone the things that aren't. Are the right projects getting delivered? Are you holding the quality bar? How is your team's morale? Are you championing the good work of your employees to other folks? This is what I hope for in a good manager, not whether I punched the right time card slot on my TPS report.