First question: SOAP is the older technology, and REST is the new and improved. REST has made us rethink how we do some things, and retrofitting is still going on.
Second question: I use the oauth all the time in the SOAP header. Mine is slightly different than what you find on the code@ site, I've posted it below. Let us know if it works, and we'll update the code@ site.
<soapenv:Header>
<fueloauth xmlns="http://exacttarget.com">hs828jcnjkwq2bhkve3j4va3</fueloauth>
</soapenv:Header>
Out of the box, OpenID Connect authentication provider that SF ships does not support resource owner password grant type/flow (grant_type = password). So while you can create an instance of Named Credentials and set authentication protocol to oAuth 2.0, to perform a resource owner flow against a 3rd party resource you'll need to roll your own, custom authentication provider. That is my recommendation. Here's a good example to use as a starting point: JWT auth provider
You can use Named Credentials without an authentication provider. With oAuth as the protocol you'll be (mostly) rolling your own implementation. The only exception: JWT access tokens and JWT-based exchange flow; Named Credentials supports them natively. For all other oAuth flows and/or token formats Named Credentials is merely a placeholder, the work has to be performed by an authentication provider.
If you want to use Named Credentials without an authentication provider, it still offers some value versus coding everything in Apex. Namely, you can parameterize the target endpoint (URL) as well as username + password values required for resource grant flow. The latter can be done by using the Allow Merge Fields in HTTP Body feature of Named Credentials and setting authentication type to Password Auth.
If you squint at these two options, the second option (custom Apex classes + Named Credentials) is not a whole lot less work versus the first option (custom Auth provider + Named Credentials), thus my recommendation above.
Best Answer
Mutual Authentication & Oauth are two different authentication mechanistic.
Mutual Authentication: Allows client and server to identify and authenticate each other by using certificates. Ref: http://www.aboveandbeyondcloud.com/mutual-authentification-salesforce/
OAuth: also identify and authenticate user but using user/pass on salesforce site, so user do not need to reveal his password to 3rd part application. Ref: https://developer.salesforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com
And yes, once the authentication is done we can consume any API (REST, SOAP, Bulk ..etc)