devDependencies and dependencies, with a little explanation, is really how you categorize packages your project needs. Dependencies will be installed in production, while devDependencies won't.
In short: the "dev" part is for dependencies you only need in your development environment. Test runners, linters, your build tool, pretty much everything that is not required for your code to actually run. These packages should not (and in most cases will not) end up in your production environment. Dependencies without the "dev" prefix are different: they are in the final bundle your users will interact with.
devDependencies on the other hand are packages which your app itself doesn't need to run, but are needed during development of the app. For example, a linter, a test runner, a build tool, a transpiler, those would all be in devDependencies. When you run `npm install --production` locally, or in a CI/CD system, those packages won't be installed.
Those little "status" badges (usually like shields.io or similar) in GitHub repos are just checking your dependencies status (passing/up to date/etc). There are a bunch of services, like David DM or Snyk or Dependabot, which just scan your package.json and check to see if the version of a dependency is still the latest published one, or if you have some old one that has known security vulnerabilities—)
You may have noticed some developers are quite strict about keeping everything green but I'd argue they are missing the point a bit. This status tracking isn't just important to make sure your local dev environment keeps working correctly (although devDependencies being a few versions behind isn't ideal, it's not usually the end of the world). Keeping track of devDependencies is important to make sure everything you depend on for your local development workflow is known and not out of your control in some sense (more on this in a bit).
Let's talk about some weird corner cases here. As I mentioned above build tools and bundlers are supposed to live in your devDependencies but they are also pieces of software that can still break your day if there is a bad release. Imagine your webpack or Rollup config suddenly starts failing because of a bug in the latest version and you have no way to opt out. "Dev" doesn't imply these packages are "unimportant" it just means "isolated to your development/build pipeline". A broken Babel version in devDependencies won't cause errors in production but it will prevent you from actually deploying any new code which is arguably worse.
We are on the case with the badges a bit now because security patches are a big reason why status tracking is important. As soon as you see a dependency is out of date (as indicated by a red badge) you should first check what has changed between your current version and the latest release. Not all new versions are security releases and some upgrades may be major. These are valid reasons to not upgrade immediately.
Of course devDependencies can also have security vulnerabilities. Think about cases where testing frameworks or other dependencies were tampered with to steal credentials from developers' computers. It's not a common attack vector but there are some documented examples of these kinds of attacks and the whole "supply chain compromise" thing is real enough that you can't just ignore devDependencies being out of date.
But automation is the point here. If you run status badge services for your projects you can also set up CI checks that ensure your dependencies (and devDependencies) are never allowed to fall below a certain threshold. Your team might choose to only enforce this on actual production dependencies, or you may have a policy that every package must always be at its latest published version. Dependabot and Renovate can (and by default will) send PRs for devDependencies as well as dependencies so I have definitely gotten burned a few times by tooling automatically opening PRs to update dependencies I no longer use regularly but have also forgotten to remove from package.json.
devDependency status badges are basically an eggo thing in the open source world? Projects that keep their devDependencies up to date are in some sense signaling that they are being actively maintained, even if their core codebase is quite old/stagnant. It's a heuristic that (incorrectly) indicates the project maintainers are still paying attention and probably willing to respond to new issues. Super shallow metric but people definitely notice a green badge with the last commit 2 years ago.