I agree. But it also depends on the type of work. If someone is acting in some kind of project delivery lead function, it is often necessary to be in the loop of many coordinating conversations. This kind of role might not be a good fit for part time, unless the rest of the team is also part time with a similar schedule.
For other kinds of work that can be performed independently with less regular check ins, it doesn't matter as much.
There are ways to structure a company to make varying schedules more or less feasible. If one piece of work is shattered into a large number of small tasks and scattered between teams with a number of maker/checker review points, then it might not be possible to complete a single item of work without e.g. 3 people in different teams reviewing it and approving it. If the content of the work is e.g. a trivial configuration change that takes 1 minute to author, then you end up with a situation where the process will become exponentially inefficient if some of the people involved work in part time schedules or inconsistent timezones. If instead work is structured into larger chunks that can be done by individuals with infrequent synchronisation points, e.g. deeper analysis / design / implementation tasks, then maybe varying schedules or timezones does not impact efficiency as much.
That is orthogonal to part-time. Even with part-time you can agree on a common core time where such things can be handled. I also had cases where timezones were quite useful. (In the evening I sent work of the day to QA and in the morning I got a test report to work on)
My concern is around all the non-core tasks, which you can't cut away proportionally when working less time, leaving overproportionally less time for the core job.
For other kinds of work that can be performed independently with less regular check ins, it doesn't matter as much.
There are ways to structure a company to make varying schedules more or less feasible. If one piece of work is shattered into a large number of small tasks and scattered between teams with a number of maker/checker review points, then it might not be possible to complete a single item of work without e.g. 3 people in different teams reviewing it and approving it. If the content of the work is e.g. a trivial configuration change that takes 1 minute to author, then you end up with a situation where the process will become exponentially inefficient if some of the people involved work in part time schedules or inconsistent timezones. If instead work is structured into larger chunks that can be done by individuals with infrequent synchronisation points, e.g. deeper analysis / design / implementation tasks, then maybe varying schedules or timezones does not impact efficiency as much.