You could compare the video in the raw folder against the final screen share video and see if there's a noticeable quality difference. The screen share video is sent through this script for processing,
https://github.com/bigbluebutton/bigbluebutton/blob/dce2e6c86094a9fab1cd15aa01ef95f73b9d7c1c/record-and-playback/core/lib/recordandplayback/generators/video.rb#L83-L137. The recording scripts are one of the parts that I've touched the least so it's mostly a black box for me.
As for the difference in quality between applications. The first video was created by ActivePresenter which is a native application that stores and the writes the information to a local file. I would basically always expect that a native application that doesn't care about sending it over a network would be the best quality. They can choose whatever codec they like and the only limiter is the hardware on the local machine. The next best quality was the Windows RDP and that also is a native application that sends the stream to one destination. They can do whatever they like with codecs, but they do have to cut some quality because it has to be sent to another computer. The worst case was BigBlueButton and it's also the most restricted because it lives in the browser and is designed to be sent to a classroom of people. Being in the browser means that we're limited to whatever codecs they want to support (H264 and/or VP8) and we have no visibility of the host or receiver computers' capabilities. If we set the quality to the highest available we'd run into issues with medium to lower-end computers and most residential bandwidth speeds. The reason I bring all of this up is because even if we set the frame rate and resolution to the highest we could we'd most likely run into other issues. If the desire is to have a very high quality capture of the screen then it's probably best to look elsewhere.