Its not clear if your performance concerns are related to the request time resizing of images, or in general to the way DD4T manages binaries.
On the performance of request time image resizing, yes it is an additional processing step, but it is only done once per image/size, not on every request for that image/size. You have to balance this performance hit, with for example the alternative of resizing the image to all required sizes at publish time. This will slow down publishing, and also build a dependency to require content to be republished if you want to alter the dimensions of images used in your web design (or add a new format). You have to decide what is more important.
On the performance of DD4T for binaries in general, checking the FS is a pre-requisite of any web application which serves binaries from the FS, so thats not a DD4T specific concern. What DD4T does do differently is check the last published date of the binary to ensure that the version on the FS is up to date. These last published dates are stored in the DD4T cache, so I don't think the overhead is that great, but if you have concerns, perhaps load test it to put your mind at rest and if its not sufficient introduce your own check/cache strategy.
