There is no such thing as a bidirectional "git integration" that simply and transparently mirrors the state of your Salesforce org to and from a Git repository.
The problems you are confronting are well-studied in the Salesforce community, and I'd recommend you take advantage of the wealth of resources that have been developed over the last few years on how to achieve source-based development on Salesforce. There are a number of viable methodologies and the right one will depend on your team, process, and budget.
But broadly, what you need is a comprehensive SDLC based on Git as the source of truth, with deploys happening from your Git repository. Your Git repository should contain only those metadata components you build or customize; there's no need to retrieve the standard objects that you are not customizing. Your goal of a 1:1 correspondence isn't completely infeasible, but it's also not useful.
In that SDLC, you'll need to carefully define where (in which environments) engineers make changes, and a branching structure for how those changes are committed, tested, and moved to production. If you permit changes in Production, you'll need to design a strategy for retrieving and committing those changes as well. Commercial tools may help significantly there if you have this issue.
Source tracking is not an option since it doesn't pull and pull the entire list of objects, just the ones that have been changed after the arbitrary point in time that I switched on source tracking.
Source tracking is a tool that you use during the development process as you make changes. It is not suitable for starting a Git repo. To do that, you'll need to identify all of the components that are in scope and retrieve them. Then, source tracking will support you as you continue development by identifying and retrieving further changes.
With deletions I can't even use an asterisk, which means that I have to manually specify EVERY deleted file in the package.xml.
You should use automation to construct your destructive changes deployments. CumulusCI (my team's FOSS product) can do this, but so can other community SFDX plugins and commercial options.
In any case, this is closer to a feature not a bug. Using wildcards to perform component deletions is something that is rarely needed in a development process and rather dangerous.
When making changes via the GUI, even when I do get the right list of objects to be pulled/fetched from my org, some of the settings (like the objectpermissions on the profile) are casually cut out.
Managing Profiles in source control is challenging. The Metadata API behavior is discussed in the documentation. Third-party plugins like SFPowerKit include additional tools that may make this process less painful for you.