I'm less familiar with ffmpeg, but the openssl(1) command wasn't originally designed to expose the API. It was intended to provide very rudimentary examples for using the API, and perhaps operated as a useful development tool for contributors, but that's it. There were plenty of APIs it never exposed, and plenty API changes it was never updated to accommodate. And IIRC there were some breakages along the way.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.
The same is true of ffmepg. The api documentation even links to the source of the bins so you can read the example code. To pick on ffplay, I think it most clearly illustrates this - with the bare minimum rendering context to get video on the screen but clean code continously updated to reflect the api's best practices, and an invaluable resource when I was writing an embedded player for a game.
This changed after the Heartbleed fiasco. One of the many criticisms of OpenSSL maintenance was that people had come to rely on the command utility for production despite the official lack of support. The libressl fork made long-term maintenance and backward compatibility promises of the command utility explicit. Subsequently, the reorganized OpenSSL project also adopted this mandate.
Still, I'm not sure you could say today that the command utility is now designed or intended to expose the API. For one thing, backwards compatibility is now the primary concern regarding the utility, but the underlying APIs have changed considerably (including in some cases wholesale shifts to a different model) as part of improvements efforts for the OpenSSL API, ABI, and overall implementation. So in some ways the utility is even more divorced from underlying OpenSSL architecture than before. And this shows in the ever increasing set of options which often don't directly map to the underlying APIs, or for which their implementation in the utility is complicated by interaction with older options.