In short, sed will not match the expected pattern without the \+. Try it:
echo '<ias-instance id="SOA_BLD02_CAS.bld02cashost01.myorganization.com.au" name="SOA_BLD02_CAS.bld02cashost01.myorganization.com.au">'| sed 's@.*name="\([^.]+\)\..*@\1@'
On my system, that command re-prints the input--no modifications. In other words, sed saw there was no matching pattern for its substitution.
As I understand it, without the backslash to escape it, sed will interpret the + as a literal character to match--not a pattern modifier.
I ran some tests, and the unescaped + causes some odd results. It appears to act as both: a literal + and a pattern modifier at the same time
$ echo "D_Hnope" | sed 's@\([^n]+\).*@\1@'
$ echo "D_H+nope" | sed 's@\([^n]+\).*@\1@'
I'm sure there's some documentation out there that explains it. Though, there seems to be too many
types/groups of regular expressions. Basic shell regular expressions, extended, Perl, and who knows what else.
One instance of my alleged "documentation out there" appears to be this page
This is a consequence of invoking sed without and with the -r option. This is the same reason why the parentheses are escaped in my expression--otherwise sed will want to match a literal open/close parenthesis.
Using '-r' tells sed to use "extended regular expressions." I won't pretend to know all the differences between them, but it appears that one key difference is that, with basic regular expressions, literal text is assumed for characters more often than not.
My preference is to have something to catch my attention in an expression if I'm doing something that is not a literal match. The escapes are that flag for me. But if you're the type of person that wants uncluttered expressions and prefers to escape the metacharacters to match their literal values, then the '-r' option is probably more your style.