Of course, you and I both can assemble thousands of tasks for which types are better suited. They would probably comprise the overwhelming majority of a random sampling of everyday coding tasks for professional developers. Having an opinion about what works best for you certainly isn't dogma— but deciding that your perspective is better for everyone else, too, regardless of the person, their needs, and the circumstances, is unambiguously dogmatic.
Many coders will never touch the complexity of most full-time developers' simplest code, and they deserve tools that meet their needs, too. How much future burden will explicit type declaration relieve for an indy self-taught web designer taking strings and floats from a database through an ORM and putting them into a for loop for a web-based coffee shop menu hosted on WordPress? I'd say none. Considering that WordPress runs 37% of websites and 62% of CMSs, I'd argue that there's plenty of room for blunt instruments to do blunt work. Insisting people jump through the types hoop for posterity is not reasonable.
As a long-time developer turned designer, I'm confident that using a "pack" layout strategy in many GUI libraries will consistently produce worse results than properly assembling a quick grid layout. I have my collaborators avoid it because using it == guaranteed re-write... but there's a lot of selection bias there. If teams involve someone like me, that probably means usability is paramount. As crucial as usability is, sometimes speed, convenience, and not needing barely-related expertise is more important. A developer making a dialog on a small internal utility should probably use pack even if I wouldn't. I have the patterns, organization, and syntax in my head to pull simple grid-based layouts faster than they will use 'pack.' For them, it's a bit of mental overhead for an already irritating task with no real payoff. Saying that languages shouldn't even make pack available to developers would be plainly unreasonable.
Even in the tasks you cited— I was a developer in a large library with a ton of older electronic assets. I processed significant amounts of CSV and other messy text files in many dozens of projects using everything from C, shell scripts, and Perl in the earlier days to Python, Elixir, and JS in the latter. I can count how often difficult-to-pin-down data type ambiguity burned me using zero fingers. I guarantee you having to futz around with types rather than throwing in an instance check or the like would have reduced my efficiency. If I had finicky or complex or relational data that needed to maintain integrity through a nontrivial pipeline, then I wouldn't think twice about implementing them.
In general, asserting that your way of doing something is universally better than other common ways of doing something is almost guaranteed to be dogmatic. For it not to be, you must provide a universally applicable truth that trumps individual use cases and people's preferences. "It avoids entire categories of bugs, near their source" doesn't work for people who will likely never encounter those categories of bugs. Insisting others are wrong for not agreeing with the accepted best practices of people who do regular professional dev work is absolutely dogmatic.