Conflict with Block Field

Got the same here.
I didn't investigate a lot, but provide this little patch to bypass the error by testing if $block variable is not NULL.
Available for 1.x-dev and 1.0-alpha1 I guess.

Confirmed that the issue appears not just when a block is saved to a block field, but also when said block field is rendered in entity view mode and as part of the entity editing form. This patch fixes the problem as far as I can tell – thanks for putting it together.

I can confirm that this patch bypasses the error. Also, I've figured out why it isn't working and I've submitted a patch to block_field to fix the issue (see https://www.drupal.org/node/2858774), but in reality I'm not sure which of these two modules is misbehaving.

Block::load expects the block ids to look like this: "views_block__view_name_block_1"

block_field is passing this module a block id that looks like this: "views_block:view_name-block_1"

The fix is just a str_replace hack. I'm assuming there's some official function in the Drupal API that does this the real way, but I haven't been able to figure out what that function is, and it's also not clear to me whether block_class should be doing it on its end. In either case, my patch to block_field fixes the error while retaining block_class's functionality.

Logic from comment 5 will not work because that id that block_field is setting is plugin id and not block id - for example this will fail for contact blocks.

As @berdir stated in block_field issue we should remove that id, new patch in https://www.drupal.org/node/2858774#comment-12063465 is doing this. As a consequence you will not be able to assign CSS classes over block_class module to field referenced blocks, but that kinda make sense because block_field is referencing custom blocks and block_class is operating on blocks added to block regions which are two different things ;)
Yeah maybe not the perfect solution but at least no more fatal PHP exception.

Note that #2858774: Compatibility issue with block_class module fix is committed, you can now test again this issue with latest block_field dev version.

Arguably this is a combinatorial bug, so not really "Block Class's fault", but I think it's still useful to mark it as a bug report rather than feature request, if only so that it can be visible at https://www.drupal.org/project/issues/block_class?categories=1&version=8.x (just like its duplicate #2858773: Compatibility issue with block_field module was, until I just closed it!)

Also had similar issues with blocks from the facets module.

Perhaps this module should load the block in a more reliable way?

I too had problems with the D8 version of TB_Megamenus. This patch is needed to prevent a lot of combinatorial bugs.

I can't see how this would conversely effect the module. If the block id does not find a block, there will be an error. The function should check if it is null since there is no guaranteed contract with any upstream block producer to have a valid block id. Checking is not a performance drain so why not make sure the code does not create a page stopping error.

Looks like this check has made it into the code in commit 0a399652.