I doubt there is a good solution to this. Indeed, traditionally print/1 does not emit quotes. I think this is wrong. Print/1, using portray/1 is first of all meant for user interaction and notably debugging. All the user-facing tooling (toplevel, debugger, etc.) uses print/1 to print terms. There a were just too many people confused about the exact type of an object that is explicit when quotes are used. Strings make this even worse as it makes "World" and 'World' print the same way.
The main problem with print/portray is that the mechanism is inherently non-modular: any module you may load that adds portray rules may upset the desired way terms are printed.
The normal way to resolve this for a dialect emulation would be to goal expand print/1 to sicstus_print/1 and then hack a little to temporarily redefine it. In most cases though, print/1 is called through format/3, debug/3 or the toplevel and these are unaware that the desired action originates from SICStus code.
Bottom line is that code should not use print/1 if it wants precise control on how the term is emitted unless we are talking about a stand-alone application where we know the code is never to be combined with any other code.
Prolog output is a mess 
Best practice seems to be
- Use format/3 to emit non-term output
- When writing a library, use the print_message/2 indirection for talking to the user
- Use writeq/1 or write_canonical/1 to write terms that need to be read by Prolog.
- Use portray_clause/1 for listing clauses. This predicate must ensure that reading returns the same clause given the same operator declarations).
- Use print/1 only for debug/3 and other interactive use of your program.
- Be careful with portray/1. Only use it for very specific terms for libraries or better, include a dedicated portray library for a specific library. rdf_portray.pl is such as beast for dealing with RDF.
- write/1 should never have been added to Prolog.