This goes against approximately everything I've learned about process in the last 10 years. In fact, I think there's literally nothing correct in that whole paragraph. It's a perfect caricature of precisely what I think doesn't work.
* Priorities are complicated. What if a high-priority item is going to take a really long time, compared to other items? Maybe the "product owners" would want it earlier. They won't know until you tell them. What if the ticket is actually technically impossible? Establishing priorities requires discussion.
* Related: how can you possibly have the product owners establish the milestones without figuring out what it's going to take to accomplish? Sometimes milestones have external drivers for functionality or deadline, and sometimes they're just checkpoints. But either way, it would be crazy to assume they're fixed relative to how long or hard their constituent items are. There are probably a million ways to construct a milestone, but I can't think of one that would be useful without a discussion with the developers.
* What's the correct granularity for a ticket? How would the product owner know how to break that down into specific work items? You need to own your own work queue.
* What the hell is a product owner, anyway? I understand there are various stakeholders and people whose job it is to play proxy for those stakeholders, and perhaps you have even formalized a PM role for managing all that. But invariably one of the stakeholders is you. That's partially because you're involved and presumably have applicable experience building products, but also because as the developer you care about aspects like infrastructure quality, and you need to represent that in the discussion of priorities. In my experience, everything works better with developers involved in the "what are we building?" process, not just getting work thrown over the wall to them.
* Why does the product owner, whoever they are, get to assign who works on what? What if I don't want to work on that item, or have a good reason why it should be assigned to someone else?
* How could this level of detachment from the why of the product ever make you happy?
More generally, this manifesto seems built around the idea of minimizing communication. That's a really bad idea. Building things is complicated and you need to have a process that's willing to face that, not bury its head in the sand and tell everyone to just create and assign tickets. Look, I don't disagree that meetings are painful and I'm always the jerk who wants a crisp, actionable agenda and gets pissy when things drag on. But replacing real planning with "just assign me stuff to do" is crazy talk.