No, this command executes several other commands (config:cache, route:cache etc) which are enough to cache anything a typical app needs to cache. Unless your app has some custom requirements (which you would know if there are any) you don't need to cache anything else.
But I advice you to examine what exactly is cached and how it affects behaviour of the app, there are some surprises and caveats.
No, cache storage is not committed to repository (you can see storage/framework/ in .gitignore file), so no need to "uncache" anything coming from repo.
When you run the optimize, Laravel compiles config files, routes, events, and Blade views. That means those things don't have to be compiled during a request.
The compiled files aren't committed to source control. That wouldn't work, and it would also be a security issue: the configuration files are compiled using values from the .env file (or existing environment variables). You have to run optimize in production.
When you run optimize:clear, it deletes these files. That means environment variables and route files have to be interpreted on every request. They aren't recompiled automatically. Always run optimize after you deploy changes.
Neither of these commands affect the actual application level cache, which you control through code. You can flush that by calling php artisan cache:clear.
If you run optimize on production, then you should run it on every deployment. There is no need to clear first, just re-run optimize after your new deployment - otherwise your app will be running old routes and config.
