This is 100% bullshit and you (should) know it. You tout yourself as some sort of RDBMS person, but you come across as knowing absolutely nothing.
At the end of the day, Firebird, Postgres and Mysql all really only support one index type (or variant): b-tree. No matter where your data is presently (index or ram), you will ALWAYS pay a price for insert, and ALWAYS pay a price for select. Now, the number of i/os required for a btree seek is a very attractive equation for anything under the 10s or even hundreds of millions mark. If you're using a quote "standard server", it's exceeding that, or having to write where things _really_ start to suffer. Couple that with that foreign keys, which usually have a btree as well, and all your combinatorial indexes, and you're fucked with any reasonable large data set. There is no disagreement here, unless you suggest that btrees are infintely fast, or that postgres does indeed have a better index (It does have hash, but it's a piece of shit).
If you want to know more, I suggest you investigate the CAP theorem and apply some critical thinking skills to the age old question - given these tradeoffs and relationships and my tolerance to any given one, what is the best tool for the job?