There are a few problems going on here:
Placeholder scope
It’s important to note the intended scope of the metadata placeholders, in the documentation (Help ▸ List of All Placeholders). Particularly where it comes to compile, there are only a handful that will work in most contexts—especially global areas. The main reason for this is that most of the placeholders pertain to individual chunks of text, rather than the global document that compile will be producing, as a whole.
For example, what is <$keywords>, in the Metadata tab of the compiler meant to do? You could have thousands of items in the draft folder, all with their own keywords—which is it supposed to use? There isn’t a good answer to that question, so placeholders such as these are ignored in global contexts.
The main exception is in the Section Layouts compile format option tab, as well as the Styles prefix/suffix fields. In those cases, these generate content that individual binder items will use, or the text within them, and so having a section layout or style insert a placeholder becomes synonymous with using it in the text editor, and it pulls its data from that item the text comes from (not some global area).
Printing is not PDF production
In your screenshot you are printing, which sends data to the system’s print drivers through standardised dialogue boxes. While it is true that print dialogues have ways of saving a PDF of the print data, you will get better results using the PDF compile setting, if it is your intention to make a PDF. I’m not sure what it would mean to set the metadata of a print job, and in fact that you can even see these fields at all when printing is a bug.
Placeholder names
Custom metadata placeholders are formatted as, <$custom:FieldName>, to avoid clashes with built-in placeholders. You provide a good example of this in fact, by creating a custom metadata field called “Keywords”. There is already a keyword system in Scrivener, in the inspector’s metadata tab for each item, and it uses the <$keywords> placeholder.
Again though, these are item level placeholders, they won’t do anything in the page header or footer, or the document title, or metadata fields.
I doubt the above helps you much in a practical way, unfortunately, since it seems you are trying to do something Scrivener just doesn’t do. I can only presume you produce multiple PDFs from this one project, and wish to somehow automate filling out these fields, but there isn’t a good way of doing that.
Well, Scrivener can do it, but you would need to gear your work over to a Pandoc+Markdown based workflow. That way of using Scrivener allows for metadata to be defined by formatted text in the editor, and thus each branch in the binder can have its own document configuration settings.