I've played around with turning a bunch of still photos into a h.264 slideshow, mostly to compare the compression efficiency of JPG vs. h.264. I got some useful replies about the technical implications of this from x264 devs on doom9. e.g. force x264 to not use B frames for this, because not-very-related images will need a lot of I macroblocks, and coding them in B frames is more expensive.
Software player behaviour with low-fps video isn't ideal, in the past. I think one older player only checked for keyboard input when it displayed a frame. So there was lag between user input and player response. mplayer2 and mpv don't have this problem. Also, players that can only seek to keyframes will seek in really large chunks (2 minutes or so!) if you don't reduce the keyframe interval. x264 won't insert IDR (GOP boundaries) all over the place if the images are somewhat related to each other.
x264 -tune stillimage. It cranks up the psy optimizations, because temporal stability isn't an issue for this use-case. Further search results: from google.
I'd agree with other suggestions to have some duplicated frames, to bring the FPS up to at least 5 or something, just in case of bad players. However, smartphones / tablets should have no problem playing variable-FPS video, since they usually record that way when light levels drop. Since variable-FPS videos from phones are now out there, hardware player support for them should be expected. I wouldn't expect problems, but I also wouldn't be surprised if there at least some old hardware players that don't handle it well. A frame of all "skip" macroblocks only takes about 20bytes at 1080p, IIRC. One reason I don't like duplicated frames, though, is that it interferes with single-stepping to go through the images manually.