If it ever was unprofessional, it may not be anymore. Early on games used their own package-formats, primarily to preserve their intellectual property (IP).
You can overcome some limitations such as fragmentation and unnecessary function-invocations of the underlying native file-system, by packing all resources into a single archive. This makes fragmentation events less likely when deploying the package on the client's PC.
In the worst case scenario you might end up having tiny individual file-resources scattered around your hard-disk sectors. (With the arrival of SSD's this point is often rendered moot)
But all of these benefits can also be had with the free, (Unix) age old .tar
archive format.
Additionally, by using your own package-format, you can overcome limitations such as the lack of versioning, file-hashes, encoding and pointers/links within files, to name but a few.
Concluding, I would argue for transparency in Indie-development, unless you explicitly need to protect your IP.
As for the great points raised by MGOwen
: To prevent Spoiling surprises you can rename the file extension, change file attributes, use uncommon media formats, excise the media-header and store it elsewhere, etc...
To prevent Losing challenge use a binary serialization writer to store your game's state, with additional encryption and decoy-variables if you must.
Disclaimer: I am not a game developer. Only regard this post as a starting point...
sound.dat
. Using uncompressed folders with a couple of hundred files makes the (de)installation quite annoying. \$\endgroup\$