Whether or not a 301 OR 404 HTTP/1.1 response to a malicious attackers
POST or GET request actually stops them from 'posting' or 'getting'?
The "attacker" sends a post request to the server, the server receives the request and responds to it with a code and maybe some content.
For a 404 code for instance, it's a common practice to send an html page with the 404 error as well.
What the server does with the request upon receiving it depends on the server. If the POST request was to insert a record in a database the server could very well insert the record in the db and then reply with a 404.
It would be a crappy implementation, but it can certainly be done.
Can these response codes inevitably help the attacker out?
Of course. The response usually contains headers with information about the server. Even if you disable the headers, the response can be used to obtain information about your server with fingerprinting techniques.
How helpful this information is will very much depend on context.
Are there better ways to have servers response to external request
(how?)?
I'm not sure what you're asking here. You can disable certain headers, try to fool fingerprinting software like nmap, and a myriad other measures that would change how the servers respond and maybe improve protection.
But you're going at it backwards. First define what the threat you're defending against is. Once you have that you can easily evaluate the effectiveness of the different protection measures.