Those are integration tests. Integration tests are great, but not when you want to run thousands of them in a few minutes. And not when you want to have lots running in parallel, accessing and potentially making "changes" to the same files.
I'm happy to have a long running integration test suite that runs on a build server.
But while working on a project, I need fast running unit tests that I can edit and run to get fast feedback on my work. I find that "time to iterate" is key to effective and enjoyable development. That's why hot module reloading is an amazing innovation for the front-end. The back-end equivalent is quickly running affected unit tests.
So I'd rather unit test my FooFileReader to make sure it can read parse (or not) what's in various files, and unit test my service which consumes the output of my FooFileReader by either parameterising the FooFile result or having an IFooFileReader injected. ( Either works to separate concerns. )
While unit testing, I'm going to test "given that System.IO.File can read a file", and write tests accordingly. I don't want a test sometimes fails because "read errors can happen IRL". That doesn't help test my business logic.
I can even test what happens if read failures do happen, because I can mock my mock IFooFileReader to return a FileNotFoundException or any other exception. I'd rather not have to force a real-world scenario where I'm getting such an error.
In a functional world, it's the difference between:
function string -> result
and
function string -> parsedType -> result
The second is cleaner and neater, and you can separately test:
function string -> parsedType
function parsedType -> result
The second is more testable, at the cost of being more indirect.
Interfaces and factories are just an idiomatic .NET way of doing this indirection over services and classes.
Of course you can also write more in a functional style, and there are times and places to do that too.