Hand-written tests cover what the author imagined
Ordinary unit and integration tests for an authorization boundary check the scenarios someone deliberately wrote down: this role can do this, that role can't do that. This is necessary but bounded by what the test's author thought to include — it says nothing about the malformed token, the out-of-range identifier, or the unexpected field combination nobody sat down to write a specific test for.
Fuzzing fills that gap by generating large volumes of malformed and boundary-case input automatically and observing what happens, rather than relying on a human to anticipate every edge case in advance. For an authorization boundary specifically, the property being checked is usually simple to state even when the input space is enormous: does the system fail closed on all of it, not just the cases someone remembered to test.
Automated testing and adversarial review are complementary
Fuzzing is good at exhaustively covering malformed and unexpected input; it's not well suited to reasoning about a targeted, multi-step attack path the way a human red-teaming exercise is. Neither replaces the other — automated testing catches the volume of edge cases a person would never have time to enumerate by hand, and human-led adversarial testing catches the specific, creative attack chains a fuzzer's random generation is unlikely to stumble into.