The occasional disk write of 20ms or more on a volume hosting a database file is not normally a big deal.
The server-level Recovery Interval, or the database-level Target Recovery Time (aka Indirect Checkpoints, and the default for SQL 2016+) can trigger aggressive flushing, which can increase the total write IO cost of a workload by eliminating the write-coalescing behavior of the page cache.
If you set the Target Recovery Time and the "recovery writer" starts to fall behind, it will hijack your schedulers to help it catch up. This will create "backpressure" to reduce your workload throughput to maintain your Target Recovery Time. See, eg:
" If recovery writer starts falling behind resulting into long
DPLists, the individual worker threads running on the scheduler starts
playing the role of recovery writer to collect, sort and post write
for dirty pages. This allows recovery writer to scale dynamically on
heavy OLTP systems to ensure target_recovery_time interval set is met
all the time. While multiple recovery writer routine running
aggressively allows us to meet the target_recovery_time for
predictable recovery, the overall throughput of workload may degrade
under these circumstances due to additional overhead caused from each
running worker performing recovery writer activity."
Indirect Checkpoint and tempdb – the good, the bad and the non-yielding scheduler
Also if your workload requires data file reads, these will contend with the writes for IO.