A good way to think about the distinction is this:
Code and/or data in a supplementary is static, providing a snapshot that was guaranteed to work in a particular time and place. Archival presentation is assured, but it cannot be maintained and thus is likely to eventually become obsolete.
Code and/or data in an open repository is maintainable, and thus can be a "live" project that is updated and continues to be executable. For the same reason, however, it is also subject to possible destruction through a variety of means, including corrupting updates, deletion, and death of the repository. It will likely be fine for at least a few years, but multi-decade preservation is much more questionable.
However, as @Davidmh points out in the comments, there is generally no reason that you can't put everything in both places. Contrary to popular belief, there is nothing that prevents code from being distributed under more than one license. This is particularly true if you first post it in the open repository, then place a snapshot ("fork") of that repository in the supplementary information. Giving the journal control of a fork does not affect the original repository.
In many cases, however, the open license and the journal's copyright will not even interact with one another. Many journals will not claim any copyright over the code or data as code or data. Instead, the journal will claim only the right to distribute the bundle as a supplementary publication, which does not restrict the use of the information in that supplementary as data or code.
Bottom line: first put it in an open repository, then give the journal a snapshot as supplementary. In the extremely unlikely case that the journal won't take it, the open repository is still a fine place for it to stay.