There are some 50+ occurrences where the bool operator is used. I'd prefer to leave it as it if that's ok.

Steve, I'm surprised that you'd suggest getting rid of an operator bool(), why?  I thought you hated the != nullptr or == nullptr kind of checks.

FYI, the use of a variable inside an if () is considered explicit.  As is the use in conjunction with logical operators.  The only place where it is implicit is if you were doing something like:

bool foo() {
    return ptr;
}

I'm fine with leaving the bool operator in.  The only reason I said 'replacing' rather than 'augmenting' in my initial comment is because I didn't see where the bool conversion was used in this patch, and didn't see any explicit casts in the existing code.  Thinking more broadly, I do see a few uses of '!p', and one use of txPacket in a boolean expression, so it is getting used... so yes, let's keep it.  I don't see anywhere near 50 uses though; just out of curiosity, what am I missing?

You're right that my gut reaction was really opposition to the 'ptr != nullptr' checks and not against the bool operator itself.  Looking more closely at the cases where we do need the explicit conversion, I see that it's really just to generate a flag for serialization; probably overkill to make a method just for that.  I think it's more readable if you add some parens though, e.g.:
  bool packet_exists = (packet != nullptr);

Another option would be to rewrite these cases, which look like this:
    bool txPktExists = txPacket;
    SERIALIZE_SCALAR(txPktExists);
    if (txPktExists)
along these lines:
    SERIALIZE_SCALAR(bool(txPacket));
    if (txPacket)

Also, with operator bool, we shouldn't need operator!

you can't do that with SERIALIZE_SCALAR because it is a macro and we stringify the parameter.  We should probably have a version of the macro that allows for a cast though because that idiom does happen frequently.

And finally,

bool foo = bar; // implicit cast
bool foo{bar}; // explicit cast
auto foo = bool{bar}; // equivalent explicit cast (and argued as preferred by Sutter http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/)

I'm keen to file this under bikeshedding :-)

Is there a take-away in terms of changes to this patch or is it good to go?

Steve may have been bikeshedding, but I was doing was probably closer to http://xkcd.com/386/ :)

Sorry, I got headed down the wrong path because I was focusing solely on the code in the patch, and didn't realize there were existing uses of operator bool() even though it was newly added.  (And thus the explicit nullptr comparisons that were in the patch are the exception rather than the common use case.)

Just for readability, I'd prefer to see the nullptr comparisons parenthesized, as I mentioned above, but other than that this looks fine.