Those are technically 2 field updates, which means 2 workflow rules...(right?)
No, you can include multiple field updates in a single Workflow Rule.
A. I can do this in 1 process builder np but should I?-(because it's so insignificant?)
B. If I do this in process builder, should I do it using a new process or link it to another process that uses the same object?
Particularly in Process Builder-heavy organizations, it's a common recommendation to maintain exactly one process per object or one process per event per object (insert or update). Here's one example of a very complex and sophisticated Process structure. I'm not sure most orgs need to go that far unless they have a very large amount of automation built in Process Builder, but using a consistent process structure that localizes activity for a single object in one Process can help make your behaviors predictable, testable, and avoid issues with interactions between different automations.
C. Is it best practice to keep all of your "workflows" in process builder all under the same roof of that particular object?
I am not sure what this means.
D. Is there a time and place to use Workflows instead of Process Builder or are we only suppose to be using Process Builder at this point?
Sure - use Workflow Rules when you need to send an Outbound Message, which Process Builder cannot do. There's not a lot that Workflow Rules can do that Process Builder cannot, and it's easier to keep Processes structured well. They also (in my experience) cause fewer issues in terms of interactions with unsuspecting code.
See also the really good points raised in comments by cropredy and by Prashanth. Process errors provide debugging information (although it can be rather tricky to interpret), and Process Builder + Flow is an area where Salesforce is investing for the future - Workflows are not. There's really no reason to build new Workflow Rules unless you're doing something that explicitly cannot be done in a Process.