You were not clear what you mean by "didn't work". There can be many reasons that something does not perform the goal you wish, but it's still working at doing something, even if it's the wrong thing.

You should include some debugging messages so you can see in the status window if something is reaching certain locations. At minimum these messages should include $scriptline $nopath($script) so you can find them later and kill them based on the message being displayed.

One thing the debugging message tells you is whether the event-handler is even being triggered, which could be caused by having remote events disabled, which you can check by: /remote

Another thing it tells is whether something is branching the correct direction after a while() or if() condition. If you put one of these debugging echoes above and below the while(), then that can be a problem depending on whether it should/shoutdn't be seeing the 2nd echo. Once you see where the branching mistake is happening, then you can edit your echo to include extra info to see why the mistake is happening.

echo -s $scriptline $nopath($script) : $ $+ istok( %blacklist , $nick , $32 ) )
if ($istok(%blacklist,$nick,32)) { do this }
echo -s $scriptline $nopath($script)

When you echo variables you must make sure they don't touch parenthesis, commas, etc - because the rules in an echo are different than when they're parameters inside an identifier.

I also edited one of your events to make it a little more efficient. You don't care about the $numtok, you only care about each token in the list, so this avoids calculating $numtok. You can do this since the token will not be $null until you run out of tokens. Also, you don't care about how MANY wildtok matches there are, you just care if there are ANY matches, so you simply check if there is a 1st match, not counting how many matches are are. The $v1 is destroyed as soon as it encounters another if() or while(), so if you need it later on you can do something like "/var %v1 $v1"

One thing I didn't change is how you're handling $comchan. The way you are handling this, it only kicks them out of the last common channel in your switchbar/treebar, which isn't necessarily the same as the last channel they joined, or the channel you really want to kick them out of, If you want to kick them out of each channel, then you'd need to have a while() loop to do that. Your using of %ii only needs a local variable that vanishes when leaving the alias/event, so there's no need to create a permanent global variable

You may want to look at /help Event Prefixes
The @ event prefix can avoid this script triggering the ON JOIN if someone joins a #channel where you don't have the Ops powers to do any of this

Code
on *:nick:{
  tokenize 32 %blacklist
  var %x 1
  while ($gettok(%blacklist,%x,32) != $null) {
    if ($wildtok($fulladdress, $v1 ,1,32) != $null) {
      var %ii $comchan($newnick,0)
      if (%blp == 0) { kick $comchan($newnick,%ii) $newnick %blkreason }
      else { ban -u300 $comchan($newnick,%ii) $newnick 1 | kick $comchan($newnick,%ii) $newnick %blkreason }
    }
    inc %x
  }
}


Some of what you're doing can be handled in "user lists" It would've been easier to understand user lists if a list of the identifiers and commands that the users tab of scripts editor interacts with were found in 1 page, instead of being split across the help pages at

/help Remote Commands
/help Remote Identifiers
/help Remote Levels