The third paragraph you quoted refers to both preflight and non-preflight CORS requests (thus "... end up not being shared [with the requesting script] or fail the CORS-preflight..."; the italicized part only makes sense for non-preflight requests, where either it was a simple request or the preflight already occurred).
Thus, while the HTTP OPTIONS request handler for preflights should generally involve very little logic, the GET/POST/PUT/PATCH/DELETE/etc. handlers for non-preflight requests very often do lots of work even if not returning a "successful" CORS response (one that will be shared with the requesting script) due to not returning the necessary headers. Indeed, the server might not even be CORS-aware, and end up processing the request as normal without even executing any logic to determine whether or not to attach CORS response headers (or which values to set for them).
To answer your actual question: unless the server is (mis)configured such that it does interesting operations on OPTIONS requests, or perhaps if the list of allowed origins/headers/methods/etc. is unknown and you want to try to find it via a string comparison timing attack (good luck...), no, timing attacks on preflight requests in particular likely don't matter. But that doesn't mean timing attacks on unsuccessful CORS requests can't still be very effective!
For a simple example of a timing attack leaking data through unsuccessful CORS requests, consider the following scenario. You, the attacker, want to know if Alice and I have been chatting on site C[hat] recently. Site C has a search function for chat messages, and this search function is not protected against CSRF (because it's not state-changing). However, the search function uses an index to quickly determine whether there are any messages that meet the search criteria, before extracting the actual message bodies to generate links and snippets for the response page. You control site E[vil], which my browser is visiting while logged into C, and thus you can make my browser execute scripts. C doesn't trust E, so CORS requests will fail. You can nonetheless have my browser initiate a CORS request from E to C, searching for e.g. messages from Alice in the last week. You then start a timer and, when the CORS callback/continuation executes, check the timer to see if the response took under perhaps 30ms (implies no messages found, with a margin for some network latency) or over 50ms (implies that the server found messages and generated a page of results). You can even try search queries that should definitely have, or not have, results, in order to determine the timing of each sort of query.
Either way, you can't actually see the search results (because the CORS request fails; your callback/continuation is in the error path) but you can tell whether any results exist and, by fine-tuning the search query, can potentially discover some details about them (like whether they contain a particular phrase, or narrow down what window they occurred in). As with all timing attacks, there'd be some noise in the results, but you can submit many requests to get averages. This would be all unbeknownst to me unless I was monitoring my network requests carefully.