Static type checking is where you have a process that looks at how variables are being used, and then throws a wobbly if you do something weird. By this, I mean it looks at the type of each variable and uses either type annotations (bits of text defining what type a variable is when the variable itself is defined) or type inference (figuring out what the type is from how you first used it) to ensure that functions don't mutate a variable in an unexpected way. This is called static typing and is a feature built into many robust languages, such as C++ and Java. While JavaScript's dynamic typing (also shared by lots of other web languages, such as PHP and Ruby) is helpful in some ways and enables a certain style of programming, it can also be incredibly frustrating due to its ability to introduce silent errors. As we're using a transpiler to transform our JavaScript anyway (throughout the book this has been Babel, though many other transpilers exist), we can introduce static type checking to JavaScript at the same time if we want to.
This is only a part of why static type analysis is useful - the other half is how it integrates into your IDE, which allows things such as easy access to documentation and extremely accurate autocompletion. It also gives immediate feedback on developer errors, which means errors make it to production far less frequently, and are thus much faster to fix. It also helps to internally document your code, which may make it easier for others to pick up.
TypeScript works really well with D3 because it has a very high-quality type definition, allowing you quick access to documentation within your code editor. This, combined with the ability of the TypeScript compiler to provide immediate feedback on malfunctioning code, means writing high-quality D3 code is much easier.
First, a caveat: is it even worth bothering with TypeScript?
I've done a few projects in TypeScript recently and while I've really tried to like it and think that it does add a certain extra level of quality to my code, I can't argue there aren't trade-offs to using it. If you do TypeScript with "implicit any" turned off (which we'll discuss later), a lot of time can be spent chasing (or writing) the right interface to satisfy a particular function.
While this extra metadata makes code a bit easier to read and ultimately more predictable in production, there's some evidence indicating that it doesn't have anywhere near as big an effect in preventing bugs as automated testing and TDD (Test-Driven Development). It can also really slow down using some fluent styles of programming if you're already fairly proficient in a library, meaning that you may find it more of a drag than anything. For a more thorough discussion, read Eric Elliott's "You Might Not Need TypeScript (Or Static Types)" at https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b.
I personally really like writing TypeScript and using the TypeScript plugin for Atom, even if it does occasionally slow me down somewhat (in all fairness, the newer versions of TypeScript are far less verbose and much better at inferring what a particular type should be without having to explicitly annotate it). It's definitely worth trying out, but don't do so at the expense of tests, which I will address in the next section. Again, as mentioned in the introduction, how useful any of this stuff is depends entirely upon your team and the ultimate complexity of the project - if you're creating one-off static HTML and JavaScript pages for a news media publication, you can probably get away without ever having to learn TypeScript. If you're creating massive, multi-view applications with a lot of user interactivity and dozens of modules, TypeScript will be significantly more useful.
What if you want the internal documentation improvements without having to switch a boatload of tooling and what not? One solution is Tern.js, which provides TypeScript-like intellisense without the static typing. It's definitely only useful if you have IDE support for it, so check whether your editor has a plugin (most decent ones do). We'll cover that first because it's easiest to get up and running and you don't have to do much else.