Azure PaaS on the Cheap
Your focus seems to be on reducing costs, so the first thing to make sure of is to reduce the number of app service plans being used. This doesn't necessarily mean merging together apps in Sitecore, but making sure your apps use the same app service plans. There are some examples of this in the standard topologies. Note how Small and Extra Small merge some apps into the same plan.
As mentioned previously, Azure Search can be a source of cost, so if you are willing to spin up the Solr piece yourself then that can save you some monthly dollars.
No matter what topology you end up with, remember that at some point you will want to log a support ticket so there is some value in having something that is not missing pieces.
No EXM or MA
This means you should not deploy a separate Dispatch Server instance, you can save on one instance there (though it's more like saving on not adding an instance). You can see how to disable the functionality here: Disable EXM and remove connection strings
If you are not using MA, then you probably don't want to deploy any dedicated instances specifically for Marketing Automation worker or APIs, but given the UI is in the product out-of-the-box, I would not recommend removing these components. Simply have them on shared app service plans with other elements.
Bundling XP Services
There are a lot of options for what to do with xConnect and the other new XP Services (Marketing Automation Worker, Operations API, etc.). You can physically merge them, as is done in XP Single where all of them run as a single app. Or you can run them all separately but on the same plan.
Ideally, you go with scaled but sharing an app service plan, or go with two app service plans as shown in the standard topologies to allow for xConnect collection to be scaled separately from the other apps. Going with the scaled version will give you the infrastructure flexibility you will need to isolate the apps as you start seeing different load distributions in your application.
Should you install EXM/MA databases?
Just from a support and making-life-easier standpoint, I would make sure the databases are there if you can find a cost-effective way (like elastic pools) to have all dbs. You don't want to be having an issue and then wondering if it's the strange changes you've made to the architecture that are causing it.
Web Jobs?
You definitely need the one for the Search Index worker as the index is what everything is looking at for contact data. The Marketing Automation Worker job makes sure that plans get processed. Again, since MA is in the tool by default, even if you don't plan on using it you probably want this job installed. It installs on an existing app.
Message bus?
In 9.0.2 the message bus (REBUS) is only being used by EXM, but in future versions more of the software will be using it for messaging between applications and services. You probably want this here to help with upgrades and enabling new functionality in the future, but you won't actually be putting any data in here most likely.
Separate databases?
I strongly recommend you to separate collection from everything else in production. It will chew your IO resources and you don't want anything going on in there impacting anything else in the system for a live site.
