[x] Rather than returning CommandResult.empty() on fail (especially with no message!), it's a good idea to throw CommandException.
[x] You don't have to construct an array manually for CommandSpec.Builder#arguments, it's a varargs; just put in all the CommandElements normally.
[x] Use a PaginationList in InfoCommand rather than just repeatedly calling Player#sendMessage; it allows them to scroll through pages via clicking, doesn't spam their chat, and adds a bit of helpful formatting.
[x] If JobCommand implements CommandExecutor without implementing execute, then you can eliminate both the need for private classes and the getExecutor function.
[x] Make sure to override toContainer on your immutable manipulator as well.
[x] If JobDataManipulatorBuilder also extends AbstractDataBuilder, it adds auto-versioning - simply change the public method build to a protected method buildContent, and use the current version number in the call to super() in the constructor. Then, whenever you change the content version, update that number and register a DataContentUpdater, and the data will get updated automatically when first accessed.
[x] Noticing this in EffectAbility specifically, but might be other places - instead of calling orElse(new ArrayList<>()), call orElseGet(ArrayList::new) - this way, a new ArrayList won't get created every single time the method is run.
[x] In ItemRepair, you might also wanna test whether or not the durability is already 0, i.e. fully repaired.
[x] In most of your listeners, the first thing in the top-level if statement, checking if the cause wrapper such as EntityDamageSource is in the Cause, is useless if you already are using annotated arguments. If you meant to check the name as well, you can add a @Named annotation to the EntityDamageSource argument.
https://forums.spongepowered.org/t/laborus-a-completely-customizable-job-plugin/15606/2