Write Transaction dependencies define that WVALID and WREADY, both are asserted then BVALID can be asserted. So the issue can be raised there that what if AWVALID and AWREADY, both are deasserted (means that wrong control/address information)?
The issue here with AXI3 is that a slave could return a B channel write response without knowing what the AW channel write request actually was (AWVALID or AWREADY, or both still deasserted).
This was allowed because in theory your slave could buffer all the write data it receives until it sees a WLAST transfer and then it could return a B channel response indicating that the data has been received, and it then needs to wait until it gets the AW channel request to know what to do with that now buffered write data.
If you only have one slave in your system you don't need to see the address to know where to route that transfer to, or the interconnect logic could have completed an AW channel handshake to know which slave to route the transfer to, all while the actual target slave is holding AWREADY low.
So some theoretical situations in which you DON'T need to know the AW channel information before a slave can return a B channel response, but unlikely to happen in the real world.
But the AXI4 protocol, reflecting more reall world scenarios, removed this issue by stating that the B channel response could only come after both the AW and final W channel transfer handshakes have completed, so removing any concerns in this area (hopefully).