I disagree that positive lookaheads (?=...) make the problem easier. They would make possible solutions generating answers that are more efficient/concise, but the original complexity still needed for the powers of single primes (eg 17), and could allow for larger factors to be tested.

I think the most likely reason is to stay true to the theory of formal languages where the concept of regular expressions came from. See here for a description: https://en.wikipedia.org/wiki/Regular_expression#Formal_language_theory. It's arguable that what we use as regexes aren't 'really' regular expressions since in some cases it gives the programmer 'too much help' (in the case of lookaheads and and repetition quantifiers) and in others it extends beyond the capability of regular languages (like backreferences).

If the description were to change, I think listing the set of intended operations would be a good idea

I agree that making the problem "too easy" is likely why lookaheads aren't allowed, but if that is the case I think it should be made explicit in the description. Seems a little silly to me to ask for a program that generates a regex for binary divisibility by n, and then in the fine print you can deduce on your own that it bans a fairly standard feature to make the problem harder. Just say it up front if that is the case.

With "?=" you could implement kind of "and" logic, which will make the problem easier, since numbers, which and divisible by 6 are divisible by 2 and by 3.

For the quantifiers I agree with you, they would be handy. On the other hand: this is probably nothing, what is generated "automatically", this would be an outcome of some kind of optimization, but - if I understood it correctly - the goal is to generate the regex on the fly.
(tivia: if allowing quantifiers, all digits needs to be allowed as well.)

Is the allowed character set ( 01?:*+^$()[]| ) accurate?

This disallows positive lookaheads (?= .... ), which requires the '=', and quantifiers {1,3}, which require '{},', both of which are valid in the Javascript regex engine.

If those characters (and implicitly, the lookahead and quantifier features) are in fact allowed, the allowed character set should be updated.

If they are (intentionally) not allowed, it would be nice if the description made that clear and explained why -- they are both very standard regex features and the description does not mention limitting which regex features the answer should use. I wouldn't think that they fall under 'funny business', so I am unsure why they would be forbidden.

And obviously if they are unintentionally not allowed that should be fixed.