Simply having everyone do what they think is best and hoping they talk enough to sort that all out on their own is great until you have several people unsure what to work on, two people accidentally doing the same thing, and management upset because your features are taking twice or thrice as long as your guestimates.
Eventually you realize that for anything sufficiently complex you need to track what the steps are, who is doing what, and when each part is probably going to be done. You don't want to be a bottleneck, so you make it publicly available to the whole team. Then congrats, you've invented ticketing.
If kotlin2 sticks to those small enough scales, they can indulge their preferences.
Bigger organisations have more and more need for structure.
And yes, I need to have a status. It allows me to warn people outside the dev team if there are any outstanding issues or if we'll be able to soon release something. Communication is key when your team is not its sole customer.
Of course, whether that structure and bureaucracy needs to be a ticketing system is a different question.