I am against the idea of holding back for newbies.

If you think bit hacks are bug prone, needlessly complex, and not worth it, don't use them. But if your only argument is "junior may not understand", then no.

Newbies need to learn, if they always face newbie friendly code, they will be newbies forever. So yes, it takes time understanding a new technique, but it is an investment.

Later, when not-junior-anymore has to decide on an implementation, he then can chose the most appropriate among the many he saw, including bit hacks. It doesn't mean bit hacks are the best, or that he will use them, but because of his experience, he will make a more informed decision.

Note that I assumed code intended for professional developers. The situation is different if you are targeting non-specialists (ex: macros for end users) or if you are making example code.

I agree that complex bit hacks makes code less readable and should be avoided. But that's not necessarily what we're talking about here. Most common uses I see of shift operators tend to do the opposite: they make what you are doing more explicit when you do bitwise operations.

If flipping the Nth bit inside an integer or a byte array is an "advanced" technique, unfit for "application programmers" then I'm not sure I want to work with "application programmers".

I'd go even further. As long as you want to communicate your ideas via code it does not matter whether you work with juniors or seniors. You want to limit the cognitive strain caused by unnecessarily complicated code.