Are you sure you read the spec correctly?

It says:

Purpose: Contains the value of the synchronization token as it would
be returned by a DAV:sync-collection report.

That's a REPORT.

ALL the examples in the spec use REPORT, just like DAV clients we're dealing with.

Yes, sync-collection is a report, but you can query the sync-token in advance using a regular PROPFIND request, just like you would get a CTag.

They key in the purpose above is the word "as".

Purpose: Contains the value of the synchronization token as it would
be returned by a DAV:sync-collection report.

It means that the sync-token returned in response to the propfind request is the same that would be returned by a sync-collection request. It's meant to get the sync-token only, not the entire change set like a sync-collection report would return.

I use the following propfind request in CalDAV-Sync to get the sync-token in advance, along with a couple of other properties:

<?xml version="1.0" encoding="UTF-8"?>
<A:propfind xmlns:A="DAV:">
<A:prop>
<E:calendar-color xmlns:E="http://apple.com/ns/ical/&quot;/>
<A:current-user-privilege-set/>
<A:current-user-principal/>
<A:displayname/>
<B:getctag xmlns:B="http://calendarserver.org/ns/&quot;/>
<A:resourcetype/>
<A:sync-token />
<C:supported-calendar-component-set xmlns:C="urn:ietf:params:xml:ns:caldav"/>
<A:supported-report-set/>
</A:prop>
</A:propfind>

That way I know if anything has changed before I send a sync-collection request. The CTag is not part of the official standards, it's more like a workaround. That's why I prefer the sync-token if there is any.

I have to check for the supported-report-set anyway if I want to use sync-collection, so why not get the sync-token with the same request to safe an additional sync-collection request if nothing has changed.

https://github.com/inverse-inc/sope/commit/0ee64d0309ecc96a29d7c788e56246aec3606ad5