What is wrong with TOGAF in practice.

TOGAF is like a religion, so one has to be very careful about saying anything against it. But ...

There are no real facts to suggest it works in practice. Most TOGAF initiatives fail, and have failed for a decade, but everyone pretends else-wise and says the next version will be better.

TOGAF has hang overs from its origin, originators and vendor sponsors - most of  whom want to treat EA as if it is a super solution architecture (or even SW Engineering approach) which it is not.  So they suggest iterations - which make perfect sense so projects/SW - but are ill-suited to architecture and governance activities which are processes (i.e. continuous and incremental not cyclic and iterative). This is also to mistake EA for EA implementation (which is obviously a different thing entirely) just as using/applying knowledge management is a different thing from implementation a knowledge management solution/approach.

TOGAF places  requirements at the centre (which makes sense) but provides almost no information on how they should be dealt with (or what in fact they are); etc. And I suspect in their hearts they mistake business for SW requirements like most of the industry.

But putting all this aside the real issue is that TOGAF is just too abstract to be useful. What it says is often true, but is so facile as not to be useful.

If one wanted to implement Accounting one could:
a) implement an accounting system and immediately have a way to generate invoices, track debtors, apply tax codes, and have many reporting options (as starting points). One could then extend and adapt the system to meet any unique or specific needs.
b) read tomes on the locally applicable accounting methodology and tax codes and create an accounting practice using a mix of word documents, spreadsheets, etc. and perhaps creates one's own database. Then would could try and develop charts, reports etc. The system might work well for an individual who understood it well and it would keep teams of book keepers (often employed as consultants or contractors busy).
c) read an abstract method that encompasses the principles of all accounting methods globally with a set of abstract high level steps and building blocks - expressed so as not to relate to any country, organisation, domain, sector or system. It would be full of abstract aphorisms and concepts most of which make sense at some level - but provide precious little practical and pragmatic advice on what to actually do tomorrow.

The same is true for EA. As architects love abstraction, anything to get away from the business and business value, they always seem to favour c). Which is why they gravitate to TOGAF.

The challenge for many with a) is that it demystifies EA and makes it a prosaic thing anyone can use without needing to read a foot of paper on abstractions, frameworks, taxonomies, reference models, etc.   What architect will go for that?