I am sorry you have problems with that, but, setting aside the fact that this is CDI spec backed, without those constraints, I am not sure how to even implement this.

Without InterceptionFactory, you are providing the instance as-is and proxying can but doesn't need to happen. Hence the constraints are more relaxed. Also note that there are restrictions on return types if the bean is to be normal scoped, see this part of specification.

With InterceptionFactory, you need to allow for interception of the instance somehow. This somehow boils down to creating a subclass that wraps the method calls invoking interceptor chains around it. Obviously such subclass during it's construction need to invoke super constructor, hence the restriction on that. Likewise it needs to extend the original class, hence the restriction on final.

InterceptionFactory is not the ultimate tool to use for everything, it covers a very specific, rather tight area of use cases where the original class is not a bean, yet is proxyable - in such case you use producer and InterceptionFactory to make it an intercepted bean.