That is absolutely true but a good navigation in the frontend is still a must. It is not a bad idea to make this the primary navigation in the backend aswell in addition to the navigate-component. That gives the editors a good feeling how visible the content they are editing really is.
Providing special views in the backend or maybe some extra search-options is possible and often seen in larger projects.
Avoiding nodes completely is no problem. You can create flow-domain objects here with a strict data-model and a specific backend-module for editing. Be aware that you loose the easy inline-editing of Neos in that case. Be careful with that decision since as long as your domain-data represents content nodes are usually not a bad idea.
If you simply want to page trough your nodes you do’nt need elastic. But if you want to execute complex queries keep in mind that elastic can help if you run into problems there. It is no problem to add that later if you ever need it.
Redis is a bit different. If you have lots of cache entries you will need it or at least you will need a cache-backend other than the default file-backend. The point where you should think about that is when editors mention slow behavior after changing something. That is usually the cache-invalidation which is slow for the file-backend.