Yes, the [io]fstream most assuredly should support a string constructor (and a wstring constructor, as well). But don't you know that the [io]fstream stuff was supposed to be a "better stdio that stdio?", and so thererfore would have to support analogs to stdio's [f]open? Maybe they just took the analogs a bit too literally.
Besides, I think what really happened is that in pre-ANSI stream libraries, there was no string class (at least, not a standardized one that anyone could count on being there); instead, there was a mish-mosh of non-standardized ASCII character containers, many of which were called string. By allowing the one true string class to be used as an option, it could well have broken existing compilers implementations of their proprietary garbage. Both X3J11 (ANSI C) and X3J16 (ANSI C++) committees went through hoops to try to minimize breakage of existing code (IMHO, to the detriment of both languages), and it was probably thought that the risk of breakage was too great.
I would expect that C++ V2.0 would fix this rather egregious omission, and to hell with anybody's code that it breaks!