If they are being paid in a way that reflects their being competent-or-better actual engineers; expecting them to play IT isn't necessarily unreasonable; but it seems pretty dumb.
You don't want to deal with lousy IT, no matter how much money you 'save'; because that's just miserable; but if you are paying an electrical engineer to spin up EC2 instances or a civil engineer to be poking at a recalcitrant data logger rather than thinking guru-level thoughts about concrete loading, you are arguably squandering relatively expensive and rare talent on problems that a reasonably competent small-shop IT generalist is exactly the sort of person to make go away so that your subject matter experts can do their thing.
Engineers who can't handle writing(or at least prototyping) simulation code are potentially more of an issue(expecting them to whip out their l33t optimization skills to save you a modest amount of CPU time by rendering the code unmaintanable is often folly; but it's been a while since most engineering disciplines were amenable to calculations entirely on slide rules and legal pads); but even there the value of an engineer who can go from Debian_netinst_x86-64 to 'fully configured numPy environment' is something that is a trifle hard to stress over as long as they know what to do with a development environment once set up.
I have a personal fondness for generalist tinkering, so I sympathize; but I also recognize that much of my generalist tinkering is purely recreational because it involves either fiddling with stuff that I'm not very good at; or doing things that someone cheaper could easily do because I'm interested in how they work. In this case, I'd be severely doubtful of the wisdom of trying to impose IT stuff on a bunch of actual, went-to-engineer-school-and-are-priced-to-reflect-that, engineers rather than investigate the possibility of finding a reasonably flexible IT/lightweight 'CS' with strong tinkering background person who appreciates the variety of an office too small for rigid specialization and the chance to poke at a wide variety of problems; and making that person available to your engineers for fiddling with peripherals, basic network and systems administration, any EC2 jockeying, etc.