AFAIK Crafter CMS prior to version 3.0 used Alfresco as the repository which in turn uses RDBMS database as the underlying database for storage of meta data. It says Crafter CMS 3.0 is using git as the repository.
My application will involve lot of image files along with meta data and I assume image files are stored in the file system and meta data is stored in underlying database in Crafter CMS 3.0.
Also is there any particular reason crafter CMS 3.0 opted not to use JCR/Jackrabbit as the repository like Magnolia and Hippo CMS are doing?
Crafter CMS is a de-coupled CMS, meaning there is an authoring system and a delivery system that are independent. In the case of Crafter CMS, those are Crafter Studio and Crafter Engine respectively.
Up to and including version 2.5, Crafter Studio used Alfresco ECM as its primary content repository, and as you correctly indicated, starting version 3.0 Git became the persistence repository. Crafter Engine always used the filesystem and never relied on an RDBMS or ECM. Solr is used for search, and Solr runs in both authoring and delivery and content are indexed there via Crafter Deployer.
It's important to note that Crafter Studio 3.0 does make use of a small embedded RDBMS schema (MariaDB) to maintain object state and other CMS-related activities, in addition to Git. However, that database can be rebuilt based on Git state if required.
With regard to image and video-based applications: the best practice is to model these assets in Crafter, but rely on an external store (like S3, Box, Alfresco via CMIS -- all of which are natively supported, but all of which are optional) for the binary but keep the meta-data in Crafter CMS. This means the content metadata is available in Crafter Engine (via Groovy, FreeMarker or Java by loading the descriptor (XML) or querying Solr), and the binary can be transformed, transcoded as required for delivery.
Having said that, you can still just store your content object (XML + binary) straight into Git if you'd like.
So to try to answer your question at a higher level: Crafter CMS uses XML to store content and metadata, this XML can point to binary assets (creating the association). The XML is modeled graphically to generate the forms, the forms render as overlays on content for a content author to create content and ultimately result in an XML in Git. XML is indexed by Solr via Crafter Deployer (runs in Authoring and Delivery) and is made available to Crafter Engine (hence your application, which is written in Groovy and FreeMarker (or Java if you really want)).
The reasons for not using the JCR are too many to list here -- Git provides a better developer workflow, performance, scalability, devops support, etc. See the #NoJCR recorded webinar on Crafter Software’s website that covers some of the reasoning. One additional immediate resource is the arch overview: http://docs.craftercms.org/en/3.0/developers/architecture.html