Of course it will be impacted. Libraries like these are "zero-cost" only because of very aggressive inlining (not generally available in debug builds), otherwise all its operations happen in subroutines. Operator overloading is the most obvious example: for regular integers, addition is basically a single instruction even in debug, but with a library like this, it has to make a subroutine call. A call which has who knows how many layers of abstraction that compiler optimizations hasn't shaken off.
In fact, the README says as much: it has only zero time/space overhead "assuming basic compiler optimizations like inlining".
And I did actually look at the code, but at a glance I couldn't get much sense of it. The main header imports like two dozen other headers, and the "detail" folder is filled to the brim with more headers. I tried cloning and using it, but I couldn't get it to compile (which is probably mostly my fault, but I really didn't want to spend too much time on it). I did run just the preprocessor though, and "#include " expanded to 48000 lines. 48000 extra lines to compile in order to use integers. For every file you use it in.
I don't want to be too harsh here, I'm sure it's an excellent library and it does what it says brilliantly, and if you need bounded integers I'm sure it's awesome. But language like "[integers in C++] are mostly unusable" rankles a bit, and the the implication in this file is that this is something you should regularly use instead of integer types.
I personally feel that libraries like this are taking C++ in the wrong direction ("ranges" is another obvious example) and making the language less and less usable in my profession.