Bitcode and bytecode refer to an intermediate representation of object code. It is an abstract encoding that has not been fully compiled into machine code for the architecture for which you are building. On Apple machines this is LLVM bytecodes.
An open question for the library is, should bitcode be used for the library. The answer is No. There are several reasons for the No.
First, the library does not build using bitcode at the moment. We recall someone saying they patched the library to build with bitcode, but the self tests ended up segfaulting. In the future the library might build and run with bitcode.
Second, even if the library builds with bitcode, the intermediate bitcode is a bad idea because bitcode makes the code malleable and it will change during runtime. We don't want the code to change at runtime in unexpected ways.
Third, the final machine object code does not exist and cannot be audited. Often times we need to inspect the machine code generated to ensure the compiler is following our C/C++ statements as we expect. With bitcode we cannot verify the machine code generated.
The concerns are not about Crypto++ in particular. It applies to all high integrity modules, like Botan and OpenSSL, too. For example, Andy Polyakov encountered LLVM/Clang generating bytecode that broke a constant-time implementation. See Supranational | Commit 553ea28bab68.
A related topic is Link Time Optimization, where the library's machine code will change after compiling when linking to an application.