The rules "Avoid captive user interfaces" and "Make every program a filter" mean that you can't write a text editor.
Not true. Some text editors are of the UNIX nature, and some are not.
But, the fact is that you probably shouldn't be writing a text editor today. Editing text is a solved problem, and you'll almost certainly do it worse than emacs or vim if you try.
The rule "Store data in flat text files" means you can't write a (reasonable) MP3 player or video editing program.
Sure you can. Your playlists can be flat text. Your video queue list can be flat text. Your preferences can be flat text. MP3s and video can also be processed in a filter style (and often are conceptually so within the UI). Only problem is compressed data isn't in a form that can be filtered without first decompressing it. But, I regularly batch process music and audio files. If I did a lot of video work, I'm sure I'd also do the same with video.
Your program can certainly be a filter for those types of files. Sox, lame, and the ImageMagick convert utility are good examples of media programs that embrace the UNIX philosophy.
The point is that you shouldn't use a database if you don't need the things that databases provide beyond storage of blobs of data. Don't over-architect your file formats, don't obfuscate them, don't make it harder for users to use your code in ways you didn't envision. This is the UNIX philosophy...not that you aren't allowed to operate on non-text data.
Programs have been working with messy real world problems since before UNIX and the UNIX philosophy existed. The need to interact with non-text data hasn't sprung into existence in the past ten years. Before there were MP3 and video, there was typesetting, and scientific data analysis, and moon landing calculations, and neural networks, and telephone switching, and so on and so forth.
Programming in the UNIX philosophy is always possible, and, as far as I can see from my many years of software development, always wise.
but most of these rules are just good guidelines for writing command shells and compilers -- not coincidentally, two of the main concerns of early Unix developers
Every single problem of note that I can think of would be well-served by breaking it into reusable pieces. Sometimes this just means libraries, rather than small standalone programs, particularly on the desktop...but sometimes separate programs that happen to be used by a "main" program are the right way to go. Things like video and audio compression can be, and often are, performed by separate programs.
This separation is a win on many levels...on a multi-core machine, the new process can have its own resources, while you continue to work away on your media. It can be upgraded or maintained at a specific version more readily. It can be used by other programs or in a batch mode from a script or batch compression utility.
I think it takes someone who doesn't use UNIX on a regular basis (actually uses UNIX; not merely a GUI shell on top) to think these concepts are outdated and not generally applicable.