According to this ELF specification: ELF object file contains various sections and one of them is symbol table section .symtab which contains information of all symbols (files, functions, objects etc).
ELF contains information like name, attribute flags, type, value and binding etc for each symbol in the symbol table.
The name of an object for a file, function or object (array, variable, string) etc. actually exposes the internal information of the code. This way any person can analyze an ELF (using strings, objdump or readelf tools) and see this information and get idea of things internal to the code which should be kept secret.
For readability and maintainability we write code which can be understood by the developers. So, we need to keep using proper file names and variable names etc. We cannot obscure them using code obfuscation as it will make it difficult to maintain.
Question (edited): Is there any way by which we can hide or remove symbol "names" from the symbol table of executable ELF so that no one can get the insight of code and the executable is still operational?
Is there any way by which we can hide or obscure symbol names in the symbol table of ELF so that no one can get the insight of how code is developed (without code obfuscation)?
Depends on what kind of ELF file you are shipping to the end user.
If you are shipping a fully-linked ELF executable, running strip a.out will remove symbol table completely (but not the dynamic symbol, which must remain for obvious reasons).
If you are shipping an ELF shared library, you need to carefully control its exposed API using -fvisibility=hidden or a linker version script. If you do, strip will again remove everything except your public API.
If you are shipping a relocatable ELF object (or an archive library), then you can't do anything about its symbol table (again for obvious reason: symbol table is used to perform the final link).
Finally, your question appears to be predicated on misconception:
We cannot obscure them using code obfuscation as it will make it difficult to maintain.
The usual way to apply code obfuscation is just before you make the final shipping product (i.e. at exactly the same point where you would use strip, or any other method that would hide implementation details). Applying code obfuscation at that point will make the result difficult to maintain in exactly the same way as any other method of hiding implementation details.
Notably, you don't (usually) apply obfuscation to the code under development and maintenance (i.e. your development builds remain un-obfuscated).