If anything it would be great to see more emphasis on this, most engineers I know spend as much time planning, communicating, organising and reporting on work as they do sitting in front of an IDE.
Also, everyone I know uses sequence diagrams and ER diagrams fairly often when things get too complicated for handwaving.
I too used boolean algebra simplifications for refactoring legacy code base that had lots of nightmare if/else once.
They seem like a tool to fix mistake that shouldn't be there in the first place with otherwise methods.
I don't mind if the class called like "Software Project Planing"
ER diagrams are great for presenting a database schema (just don't get too hung up the exact arrow you're using!) When I start a new major project, one of the first things I do is an ERD. You don't need every field (column, attribute...), but the tables (entities, objects, collections, whatever you want to call it...) and their relationships are pretty important.
After some years working, it's clear it's useful in some capacity but it's easy to overdo it (like require every detail of the system to be in those formats) or misuse it (sequence diagram improperly documenting async flows).
I find it's easier to think of these data as cartesian product of a bunch of tuple. Even having table in my imagination is confusing!