There's a bit of an existential conflict with OSM and its purpose as a utility. It's hinted at (if you edit) by the plea not to edit for the renderer. As in, don't let the changes you make be dictated by how it will look in the Mapnik render, or other.
The reason for this is that OSM was not intended to be the map you see when you visit its site. It's primarily meant to be a collection of geographic information (lines, points, labels) that you interpret as you want in whatever software you import it into. The map you see when you visit (Mapnik, which you seem aware of) is just their own interpretation. It provides an obvious use and is also a demonstration of one way to interpret the data.
The conflict is that the general public are fond of dictating what something is for themselves (see the concept of Desire Lines). Although OSM was meant to be about a collection of data, not the map you see on the site, the general public's uses/actions/confusion over the Mapnik map pushed OSM into catering more to the Mapnik render as a service to the general public by adding export/routing options etc., albeit basic ones. The result of this is that you will get all sorts of tools encouraging the sharing and exporting of the Mapnik render (to cater for the demand to do so) but the heart of OSM still suggests you use the raw data via alternative means and render it yourself to your exact specification.
Basically : If you want to do something incredibly simple with the map where aesthetics and usage aren't too extravagant, the basic Mapnik sharing and exporting tools may be enough. If you want to do more, you will need to do what most professional and GIS bodies do and use more sophisticated GIS tools.
GIS is its own sea of tools and information that can be a bit overwhelming. A lot of it, unfortunately, is quite user-unfriendly stuff involving command lines and installing various libraries, etc. via the command line. There are ways around this and utilities that don't require this but it's hard to avoid if you get into designing maps in any sort of serious way. Recommendations on the OSM wiki pages can be quite diplomatic at times and not necessarily put you on track for a utility that will not leave you tearing your hair out after a week to just get running or no longer function any more.
Ultimately you will be looking to convert OSM data into either a database like
PostGIS/PostgreSQL or as
Esri Shapefiles. They're pretty close to standards for this kind of stuff. A lot of recommendations for software online will be coming from a scientific/data side. There's relevance in all but if you're coming from a design background you'll likely want to to look at the MAPublisher plugin for illustrator. I believe a lot of map illustrators for NatGeo, etc. would use it these days. If you're familiar with web-design standards you may want to check out Mapbox's legacy version of Mapbox Studio. It still has a learning curve but once you've got your map data into it you can style it like CSS and export at print resolutions. It's newer version of Studio is online-only and has all but dropped support for exporting at print resolutions (being focused on web uses).
I'd suggest putting aside some time to research all the above. There is a learning curve to the more professional route for doing this and, if time and patience is important, perhaps accepting a simpler (OSM standard export) choice may be the right one. I'll warn you that it's easy to believe that exporting a map as a vector shape like eps, svg or ai may seem like the best solution but you can quickly run into a heap of styling complexity unless your map is relatively simple. Don't rule it out, but just be aware of this. GIS databases and formats like Shapefiles help by allowing styles to be applies based on rules and filters (not dissimilar a concept to css styles in html). This is incredibly useful for visually communicating maps where you will want a coherent visual language of what the map represents based on rendering similar features in a similar manner.