One of my design goals for AFL was to make it very simple to use - because there's plenty of fuzzers that work OK when you dial in 50 knobs just right, but fail spectacularly otherwise - basically ensuring that nobody but the author can really use the tool to its full capacity.
While AFL++ is cool, it sort of ditches that philosophy, giving you a lot of options to tweak, but not necessarily a whole lot of hope that you're going to tweak them the right way. So, that's one gotcha to keep in mind.
This shouldn't be understated. I went from having never run a fuzzer to having a 16-node run executing for thousands of machine hours on a somewhat unfamiliar C++ codebase with minimal effort.
Both the tool and the documentation made it easy for me jump in, identify bugs, write new test cases, implement a fix, and verify the fix passed without issue. I've mentioned it on HN before, but AFL taught me how incredibly difficult it is, even for experts (think most senior engineers at a FAANG) in the field, to write C++ without security vulnerabilities. I was even able to find and fix bugs which were previously reported but no one was able to reproduce reliably.
While AFL++ is cool, it sort of ditches that philosophy, giving you a lot of options to tweak, but not necessarily a whole lot of hope that you're going to tweak them the right way. So, that's one gotcha to keep in mind.