I'm not 100% sure but have been looking into the same question. I believe that it can have an effect but depends also on the physical and logical block sizes reported by the disk. If so, it would affect both performance and durability.
The filesystem block size is the smallest addressable unit for the filesystem. Filesystem requests are passed to the device driver to get the data from the disk. The device driver will convert into device block requests based on the logical/physical block sizes of the disk. On Linux you can see e.g.
If the device block size is lower than the page size of the device then the requests will anyway be broken down further no matter how large they are to start with. This seems like suboptimal behaviour anyway that should be fixed first - I think it is not uncommon to see 512B on a modern SSD with 4/8KiB pages. See Changing sector size on Samsung 840 SSDs.
If the device block size is the same as the page size, say 8KiB, then it seems likely that two 4KiB requests from filesystem would result in a unnecessary second request and in the case of writes especially this would be pretty bad.
What is not clear to me is the extent to which either of these effects is mitigated by controller or OS caching. jon's answer does not provide much detail or evidence. It sounds pretty likely that reads would be cached, as this would anyway be a risk-free performance and durability optimisation. Write-caching is normally enabled for SSDs too but is optional. It then depends a bit on the cache policy/flush interval. On Windows there seems to be some confusion around write caching options (the accepted answer to What does "Write cache buffer flushing" mean doesn't really explain the difference between two settings and other articles also conflate them).