When there are multiple data files in a database, all the writes to the database are striped across all files based on the proportion of free space that the file has to the total free space across all of the files. Now, each of the data files has its own set of allocation pages (called PFS, GAM, and SGAM pages) so as the writes move from file to file the page allocations occur from different allocation bitmap pages, spreading the work out across the files and reducing the contention on any individual page. This would be your benefit.
Again important factor is how many of them are there. As a general recommendation it should be based on logical processors you have on the server. So for 8 or less keep the number equal to processors. For more starting point should be 8 and then increase by one based on testing or contention issues.
Again for write latencies you might want to check with your storage team what's the threshold for the acceptance number in your environment. For faster temp db we in out environment keep them on SSDs and make sure log file is spiltted on different drive than data files.
Also as a side note those latencies number may or may not be a problem depending upon the nature of performance you are witnessing right now.
Plus I would suggest to check on trace flags 1117 and 1118 if you are on version of sql running 2014 or lower. From 2016 onwards it's enabled by default