I'm among those who have enjoyed the satisfaction of making my own Forth-like, and I've even used it only to find the same kinds of difficulties as author. Aiming for less is always a valid approach, but it's hard to reconcile with this era of software and the benefits of sheer magnitude. It might have been less true in the early 70's when software was less of an "ecosystem."
But on re-reading this for the n'th time I think the lede of this one is in the comments. Like any guru who is selling a "right way of doing," Chuck Moore has always had a business interest in selling snowflake Forth services of some kind. He, and other Forth followers, may well believe the pitch fervently. It is, at least, a relatively self-consistent ideology, and it discards the messy aspect of building any kind of institutional presence. But it also has a kind of dogmatic quality.
I also wrote my own Forth implementation, in 6502asm, back in high school. Was great fun and a great learning experience. I later wrote a Star Trek space battle game in it.
As for aiming for less is hard to reconcile - that's where you and the majority of programmers in the industry go wrong. You should have said "aiming for less is always a valid approach." - full stop.
My LMDB database engine is the world's smallest/fastest/most reliable full ACID transactional data store. The core of the engine is less than 32KB of x86-64 object code - it can execute entirely within a CPU's L1 instruction cache. It blows away other DB engines that are several times bulkier in size. It's only 6kloc of C. It does what it does precisely by following the Forth philosophy - do what you need, throw everything else away. http://symas.com/mdb/
Efficiency always matters, even today with CPUs whose L2 cache is larger than entire computer systems of 30 years ago. Efficiency always matters because all of these compute resources have a cost - electricity isn't free, and time spent is irreplaceable.
I have other ongoing projects in Forth because it can handle some cases easily that are awkward in other languages. (E.g., an ASN.1 parser for dynamically adding new syntaxes to the OpenLDAP server. Forth is the perfect tool for the job because it's inherently a language designed for extension.)
Forth has good affordances for compact solutions. Compactness is the is the single most important metric in robust solutions. Tractable, low inertia, retargetable and emulatable are all qualities that come with compactness.
One would do well I think to explore through old code bases and algorithms for stuff that ran well on those old systems. Because memory is plentiful doesn't mean we need to waste memory bandwidth or cache locality.
But on re-reading this for the n'th time I think the lede of this one is in the comments. Like any guru who is selling a "right way of doing," Chuck Moore has always had a business interest in selling snowflake Forth services of some kind. He, and other Forth followers, may well believe the pitch fervently. It is, at least, a relatively self-consistent ideology, and it discards the messy aspect of building any kind of institutional presence. But it also has a kind of dogmatic quality.