Documentation for anything rich-media or 3D in Acrobat has always been terrible; some things in the docs have never been implemented, some things in the code have never been documented. It was never much more than a proof of concept, and Adobe decided back in the Acrobat X cycle that the concept wasn't something they wanted to push forward. PDFs were just going to be boring documents, anything "interactive" was to be done in HTML or ePUB. Rich media and 3D made it into the Adobe extension to the ISO PDF spec so they couldn't just delete the code from Acrobat, but it got zero developer attention. They offloaded the 3D bits to Tetra, and left the Flash stuff to wither. It was never going to appear on mobile, none of the third-party PDF viewers could deal with it because they couldn't bundle the runtime, and these days the vast majority of people view PDFs on a phone or in a native browser window. It's not worth the effort to develop documents anymore, unless you're targeting a closed audience who can be forced to use Adobe Reader on a desktop computer.
The two embeddable SWFs "videoPlayer" and "audioPlayer" used by Acrobat and InDesign were pretty much out-of-the-box examples of the playback widget from Flash 8, hence the strange names of the function calls, and the Acrobat managers probably assumed people would go to the Flash Pro docs for help. Then Flash was 86ed and .. yeah.
The idea of video "cue points" in the Acrobat API is strictly a FLV idea, they are detected by the (closed source) FLV decoder in the Flash runtime and so the player gets to see them "for free". They are not the same as markers or XMP data in other video codecs, and since you can't make FLVs anymore that entire concept is dead on arrival.
As to keyframes, there are some third party apps that will analyze a video file and show the frame types (I and B) but by default an H.264 encoder creates them as it sees fit, based on how much a frame differs from the previous. That's why scene changes will create one. You can usually define the average interval between keyframes to aim for, and it's possible in some encoders to create H.264 files in "all-I" format where every frame is a keyframe, but at the cost of a much larger filesize.
... View more