Update September 18th, 2020 (Solved for my use-case): I realize this may not be helpful for some people, but I was able to figure out the problem at least for my team and hope this can assist anyone else with a similar enough situation. My team and I work on a very large codebase and I only started in my role almost a year ago, so there's a lot of stuff in our codebase that I don't have direct experience with. This also includes some third-party vendors' frameworks that exist in our codebase. Most of these decisions and dependencies were made before I joined the team. With that said, I made a new Xcode project using 11.6 (the last successful version I used for distributing our app to the AppStore) and used the same Bundle ID and Team combination for it. I tested that I could upload the sample "Hello World" application which was successful. I then started introducing things little by little to isolate the issue and found what the culprit was for us. For us, it was one of the third-party pre-built binaries that was provided to us which was causing the rejection. Submitting a build without that framework resulted in a successful upload and processing, but including it resulted in the error you see at the title of this post. We plan to reach out to that vendor next week to see what we can do about getting this resolved so we can go back to including Bitcode in our releases. I hope this is helpful to others in similar situations. I would recommend uploading builds to the AppStore with Bitcode enabled and only providing a small subset of your dependencies until you find the issue. Again, this may not be helpful for everyone, but I hope it's helpful to someone. I can only conclude that rules were changed on Apple's side after the September event and that our vendor's pre-built binary has assembly or something of the sort within it. Good luck to you all and I hope you find resolution soon. tl;dr It was a problem with one of our third-party vendor's frameworks and we're going to ask them to investigate this. Steps to find resolution above.

My team and I are having a similar, but not exact issue as the one described here. I've made a new post describing what we've tried and the only solution we had that worked although it is less than an ideal solution. Someone was nice enough to link to this post as well from my own. I will leave a link here to cross-reference the other issue in case it is helpful for some people. https://developer.apple.com/forums/thread/660365?page=1

Update September 17th, 2020: Because we don't want to keep Bitcode disabled for our builds, we wanted to figure out if the problem was on our side or Apple's servers changed something after the September event perhaps. So, we decided to go back a previous commit that we released successfully using Xcode 11.6 and change the version and build numbers locally, allowing us to upload our "old" build to TestFlight. We also made sure all of our dependencies were rebuilt using Xcode 11.6 and the same versions were built that we released with to make sure it was the same kind of output. To our surprise we saw the same rejection email as stated above because Apple's servers failed to compile using the Bitcode provided. Again, this all works fine when rebuilding from Bitcode locally for a non-AppStore build (we're using Enterprise for this). This leads me to believe that some rules may have changed on Apple's side even though our binaries were fine before as they no longer are. Still looking for leads that may help resolve this issue.

Thanks, @KMT, but that link doesn't appear to have any suggestions for this either and it looks like the original poster had an issue with the beta versions of Xcode 11. I saw someone else mentioning in that thread that they're seeing the same issue with Xcode 11.7, so I'll keep an eye on it as well though in case they are related and someone has a suggestion there in the future. Much appreciated.