In my career I've seen a lot of project managers and organizations limp along on projects, in ways that could have been prevented with proper use of the WBS tool.  Here are just a few major mistakes I've seen and want you to be aware of.

Using the WBS as a task list

When I first began managing small projects, I used a task list to plan and remember what needed to be done. This is NOT a WBS, and it's not nearly as effective as a WBS either.  I was making a mistake, and it showed because conversations about scope immediately turned to how, who, and when (tasks/schedule) instead of what (deliverables).  A WBS gives you this focus for initial planning and scope control throughout the project.

The level of rigor you go through will vary depending on your project size and type. I have managed projects that lasted only a few weeks, and I used a WBS for them. I've also managed large aerospace projects over 5 years in duration.  The more complex your projects are, the more dire your need for proper use of the WBS tool!

Organizing the WBS by org structure

This is one of those natural intuitions we have as regular people; and we must recognize that and resist the urge as project managers.

Instead of being focused on the output of the project as a WBS should be, some organize it by one of the inputs, the resources doing the work. This takes the focus off the unique product(s) being produced by the project, and leads to unexpected omission of scope.

Project WBS organization

It can also lead to scope bloat!  When you try to plan a project this way, scope can creep in that is not really a part of the end product, and/or isn't really necessary to meet the requirements for your deliverables.

A lack of traceability to the WBS

Your newly created WBS should become the foundation for most other planning processes and artifacts in your project.  It will also be a living document, something that is updated as scope changes on your project are approved BEFORE they become reality.  Wherever applicable, it's critical that your project artifacts are traceable to each other.

When a change in the WBS occurs, you want to be able to easily find the places in other project documentation that require analysis and updates.  When there's a question about some aspect of your scope, you want to easily find all the relevant information about it.

Traceability allows for this.  The WBS numbering scheme becomes a kind of common language used for nearly everything else you do on the project, from all project artifacts to general communication and reporting.