It's hard to give a definitive answer and each application will need to be evaluated case by case.  The focus of JBeret (and JSR 352, the batch spec) is a batch processing engine.  Although JSR-352 standard does not define a standard for batch job scheduling, any Java EE applications can leverage the scheduling capability in Java EE Platform based on EJB timers & scheduling and managed concurrency utililites.  jberet-scheduling is an extension library that tries to make it easier to work with batch job scheduling in Java EE.  You can see some of its features from these jberet-ui screenshot:

jberet-ui screenshot images · Issue #71 · jberet/jsr352 · GitHub

evaluate whether your app is scheduling-driven, or heavy in batch processing.  If your app is deeply integrated with Quartz and uses a wide array of its scheduling features, it may be hard to find JBeret counterpart features, or may takes longer to achieve the same effect with WildFly and JBeret. 

If your app is more centered around batch processing, there is substantial benefits with migrating to a standard-based java batch solution.  You can leverge the standard xml-based job scheduling language, standard API, configurable skip/retry logic, processing metrics, chunk-based processing, task-oriented batchlet, stop and retry, etc.  JBeret also offers additional extension modules and reusable components to help with batch application development.

An important benefit of JBeret is it is well integrated with WildFly and JBoss EAP, which means you can build your application on top of Java EE the most successful and stable enterprise application platform.  In fact, jberet-schedule module uses Java EE managed concurrency or EJB 3 timer and scheduler to implement batch job scheduling.