That most of the time, these formalized processes can be sort of helpful, but for the most part it's strictly about delivery.  

I've created use cases before and most of the time they fall on blind eyes. 

It seems like to me the most documentation I have created that was used was change request forms for changes in the environment.  BRD and FRD forms and I use the term loosely to describe there forms.  A technical document usually drafted up by the development team and a test document to follow and track changes, errors etc.  

That's about it, sometimes we use a GANTT chart if there are a lot of moving parts and resources etc.  

Is this normal?  I see the CBAP - BABOK framework and it just seems like a ton of needless paperwork.

Needless paperwork is an epidemic in our field ... at least I think it is. The techniques and artifacts that CBAP - BABOK teaches are not flawed. Depending on the situation many of those tools are relevant and helpful. 

The problem is that so many projects start with a Statement of Work that specifies what types of requirements documentation needs to be captured. Piled on top of that you have SDLC processes in larger organizations that demand additional, unnecessary documentation.

It is a case-by-case basis, but most of the time we are either (1) asked to create too much or (2) we fall into the trap of thinking we need to crank out more documentation.

The first one is often an impossible situation that you cannot overcome without changing the culture of your or your client's organization. The second one is something we have control over, but often don't do anything about.