Ccrypt versus 7zip encryption

(I have never used ccrypt. My answer about it is limited to what they claimed in their page)

1. 7z actually encrypts both the archive header and the actual file content, but with the same password. When using 7z to create an encrypted archive, you have the option to also encrypt the header (through the command-line flag -mhe=on, default is off). As long as you supply a password, the actual file content is always encrypted regardless of whether you encrypt the file header.
   The use of file header by 7z (and zip and rar) is just to allow you to quickly browse through the files/directories stored in the archive, for both encrypted and unencrypted archive. tar does not have any such file list due to historical reasons.
   So your assumption is incorrect.
2. I can't say for ccrypt, but 7z is safe enough in terms of encryption (as long as you choose a good password). As you have mentioned, 7z uses AES-256 for encryption and AES-256 is safe. 7z is open source and there are no security flaws (malicious or honest) that could tamper encrypted 7z's security.
   Note that you are using a password to encrypt your 7z archive. That means if somebody got your 7z file, he can try every possible passwords one by one until he comes to your password. (That's why you should always choose a good password) 7z uses key stretching (100,000 iterations IIRC) to slow down such process, but if your password is too short or is too common (e.g. "Passw0rd" or "Letmein"), that malicious guy can hit your password quickly. There have been genuine password crackers for encrypted archives which uses this trick.

so even if someone will ever take control of the server (and not of my PC of course), he will not be able to find any traces of a decompressed archive

As long as you don't 7z x archive.7z -pMyPassword or "Extract here", the file should be invisible to other people. This is a common pitfall for automatic cloud sync tools like Dropbox: Any files that you extracted to the sync folder will be uploaded to their server. If you double click on the file in the archive file list, the file will be extracted to some temporary path (/tmp or somewhere in your ~) and the sync tools won't upload it to anywhere.

3. Yes. It's called 7z :)
   Seriously, .tar archive is nothing more than a large file. You can always compress/encrypt it using 7z. This will produce a .tar.7z file though you are free to rename it. This means multiple files are grouped into a .tar archive, then compressed/encrypted with 7z in whatever way you like. This is particularly useful in *nix administration since tar preserves owner/permission info but 7z doesn't. But in your case if you don't care about these, a simple 7z is more than enough.
   As a sidenote, you don't need to compress with 7z if you don't want. You can set the compression level to 0 (-mx=0 in command line). This way 7z simply packs your file and encrypt them, without doing the time-consuming compression/decompression.

However, even if opening a single file in the 14GB .7z archive isn't as quick as in the .tar archive

It depends on the algorithm used to compress 7z and tar files. There are multiple compression algorithms to compress a file, and each algorithm can be configured to different compression levels. In general, the smaller the output file the longer it takes. Since you mentioned that 7z saves you 100 MB there is a trade off in time.

Also, when you open the file list of .tar, you have already decrypted and decompressed all the files. It's just the matter of getting the bytes you want. But for .7z only the archive header is shown. The actual files have not been decrypted/decompressed yet. If you compare the time taken from double-click on file list to getting the file, tar is almost always the winner.

In fact, the encrypted version should take much longer to be extracted given the added decryption time

This may be true for old computers (>10 years ago). Modern day CPUs are (1) very fast in general, and (2) have built-ins for common crypto algorithms like AES. Disk IO is more of a limiting factor if you are not using SSD.

how can 7zip in only 2 minutes and a half decrypt and extract the whole archive, when ccrypt takes much more to only make the decryption??

Without knowing the filelist and which file you are decrypting/decompressing I can't say for sure. However, since tar must uses solid compression, you need to decrypt and decompress the whole archive in order to get even a single file. Whereas for 7z, solid compression is optional (but is enabled by default in command line 7z; GUI depends on which frontend you use). Each file is compressed and encrypted individually. To get a single file, just get the encrypted bytes according to 7z header, and do the magic only on those bytes for your file. tar is good as a archive format if you always want to extract the whole archive. If you sometimes just need a single file, go with 7z.

is there a way to combine UNIX basic tools to be as powerful as a 7zip archive, that is combining an archiver, compressor, and encrypter

I won't recommend reinventing the wheel / rolling your own when it comes to security. 7zip is free software and even proprietary software supports 7z format. But if you really have to, try gzip-ing individual files, tar them (no compression) and ccrypt the tar. You'll need some non-trivial scripts for that though.

Assumption 1) is incorrect. Using the password on an 7Z, RAR, ACE or a lot of older archivers allows you access to the file 'tree'. You will still have to extract (decrypt) each file if you want to actually access something. This is valid since the MS-DOS era.

So you practically access an index of your files, nothing more.

Also note, that the decryption key is tested against every file. Archivers only automate this and apply the same key for all files, but you can actually encrypt each file using a different passsword if you want.

-Edit- You can actually study the 7Z code here.