Not... sure... what this has to do with *checks title* software development...

A tool is expensive... OK... I mean... Is the emphasis on CASE tools a sign of... OK; so I don't actually know what a CASE tool is. I have a vague familiarity with the term... TO THE GOOGLES!
Oh, Compouter Aided Software Engineering tool... HAHAHAHA... OK; UML diagramer.
Right; OK... I see... Yes. This is right about the time these tools really started to get developed. Computers could DO STUFF!!!

CASE tools are overrated and the free stuff is good enough.

I tend to use plantUML for a lot of my diagramming. Any of the text => Image editors are good though. What I really like about them; and why they stick with me; I can version control the diagram and see change over time.
I also use it as documentation in the code. I'll put the text into a comment at the appropriate level. Sometimes I'll even use the ASCII 'image' in there as well.

The book's dumb.
They are expensive, but they save money in effeciency.

I'm asuming that this was a new shiny tool and got lots of attention; but let's generalize.

Good tools are worth their cost.

Spend the fucking money.

I've only backed down on getting the company to buy me the tool once. And that's because it was about $2K and I could spin up a VM w/free trial to get my task done.
The next time I had to do something similar, I got a license.

So... Good tools are worth it.

There's cost to not getting the tool. The book hits on a few; but I think it misses highlighting an important point.

Devs get fucking frustrated w/o the correct tools. This could be accounted for in the "lower productivity" and "increased employee turnover"; but ... That's dismissable by uninformed management. So let's inform.

Developers w/o the right tools CAN'T be as productive. They get frustrated TRYING to do the work... Without the right tools, the TOOL stops them from working.

I want to really emphasize this; mostly because I suffered it. If your developers don't have the right tools; they will be UNABLE to be as productive as they are capable of.

I want to provide a wonderful example of being asked to build something and provided tools and an environment that FUNDAMENTALLY COULD NOT build the product.

We had to build a Windows Store App which used Windows 10 features... on Windows 7.
With a SHITTY laptop.
I could start some of the project (AKA - create it and test projects). When we started trying to write some code, every 30 seconds the computer would hang for 15 as our security software consumed ALL THE RESOURCES.

We needed to use a feature that required our AD server to be a minimum version... We didn't have that version...

A machine that hung 1/3 of the time, on an OS that didn't support features, on a network that lacked capabilities...

Now... I'm me. "Can't" isn't something I'm very agreeable with.

I broke a few rules to make progress.
I broke a few more to keep moving forward.
I got my hand slapped; HARD.
I stopped the team from working on the product. The hand-slappers changed their mind, but we had to follow their directives.
We found a way to follow the letter of the requirements...
We got it done.

I get shit done.

If we hadn't gotten ourselves the tools we needed, we would have never; I mean NEVER; had a shot at the deadline. The delay in our tool KILLED productivity. More than once we forgot where we were after a 30 second hang. Conversations went a little longer...
We lost 33%-50% of the day to the security software; When we ... broke some rules... and used my personal laptop; we were 4-8x more productive. Distractions; gone. We could focus. It was night and day difference.

The tools do more than make engineers more productive; the lack of the correct tools frustrates and kills focus. There are so many more subtle things that demotivate employees. Those are the ones that'll stay.

OK - rants over.

Good tools, cost - Pay it.